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まえがき 


すぐにはわかりにくいかもしれませんが、 Rust プログラミング言語は、エンパワーメント （ em¬ 
powerment) を 根本原理と しています： どんな種類のコードを現在書いているにせよ、 Rust は幅広 
い領域で以前よりも遠くへ到達し、自信を持ってプログラムを組む力を与え (empower) ます。 

一例を挙げると、 メモリ 管理やデータ表現、並行性などの低 レベルな 詳細を扱う「システム レベル」 
のプログラミングがあります。伝統的にこの分野は難解で、年月をかけてやっかいな落とし穴を回避 
する術を習得した選ばれし者にだけ可能と見なされています。そのように鍛錬を積んだ者でさえ注意 
が必要で、さもないと書いたコードがクラッキングの糸口になったりクラッシュやデータ破損を引き 
起こしかねないのです。 

この難しさを取り除くために、 Rust は、古い落とし穴を排除し、その過程で使いやすく役に立つ洗 
練された一連のツールを提供します。低レベルな制御に「下がる」必要があるプログラマは、お決ま 
りのクラッシュやセキュリテイホールのリスクを負わず、気まぐれなツールチェーンのデリケートな 
部分を学ぶ必要なく Rust で同じことができます。さらにいいことに、 Rust は、スピードとメモリ使 
用の観点で効率的な信頼性の高いコードへと自然に導くよう設計されています。 

既に低 レベル コードに取り組んでいるプログラマは、 Rust を使用してさらなる高みを目指せます。 
例えば、 Rust で並列性を導入することは、比較的低リスクです：コンパイラが伝統的なミスを捕捉し 
てくれるのです。そして、クラッシュやクラッキングの糸口を誤って導入しないという自信を持って 
コードの大胆な最適化に取り組めるのです。 

ですが、 Rust は低レベルなシステムプログラミングに限定されているわけではありません。十分 
に表現力豊かでエルゴノミックなので、コマンドラインアプリや Web サーバ、その他様々な楽しい 
コードを書けます。この本の後半に両者の単純な例が見つかるでしょう。 Rust を使うことで 1 つの 
領域から他の領域へと使い回せる技術を身につけられます；ウヱブアプリを書いて Rust を学び、それ 
からその同じ技術をラズベリーパイを対象に適用できるのです。 

この本は、ユーザに力を与え （ empower) る Rust のポテンシャルを全て含んでいます。あなたの 
Rust の知識のみを レベル アップさせるだけでなく、プログラマとしての全般的な能力や自信をも レ 
ベル アップさせる手助けを意図した親しみやすくわかりやすいテキストです。さあ、飛び込んで学ぶ 
準備をしてください。 Rust コミュニティへようこそ！ 


• ニコラス . マツ トサキス (Nicholas Matsakis) とアーロン . チュー ロン (Aaron Turon) 
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注釈：この本のこの版は、本として利用可能な The Rust Programming Language と、 No 
Starch Press の ebook 形式と同じです。 

The Rust Programming Language へようこそ。 Rust に関する入門書です。 

Rust プログラミング言語は、高速で信頼できるソフトウェアを書く手助けをしてくれます。高レべ 
ルのエルゴノミクス （訳注 ： ergonomics とは、人間工学的という意味。砕いて言えば、人間に優しい 
ということ）と低レベルの制御は、しばしばプログラミング言語の設計においてトレードオフの関係 
になります； Rust は、その衝突に挑戦しています。バランスのとれた強力な技術の許容量と素晴らし 
い開発者経験を通して、 Rust は伝統的にそれらの制御と紐付いていた困難全てなしに低レベルの詳 
細（メモリ使用など）を制御する選択肢を与えてくれます。 

Rust は誰のためのものなの 

Rust は、様々な理由により多くの人にとって理想的です。いくつか最も重要なグループを見ていき 
ましよう0 


開発者 チーム 


Rust は、いろんなレベルのシステムプログラミングの知識を持つ開発者の巨大なチームとコラボ 
するのに生産的なツールであると証明してきています。低レベルコードは様々な種類の微細なバグを 
抱える傾向があり、そのようなバグは他の言語だと広範なテストと、経験豊富な開発者による注意深 
いコードレビューによってのみ捕捉されるものです。 Rust においては、コンパイラが並行性のバグも 
含めたこのようなとらえどころのないバグのあるコードをコンパイルするのを拒むことで、門番の役 
割を担います。コンパイラとともに取り組むことで、チームはバグを追いかけるよりもプログラムの 
ロジックに集中することに、時間を費やせるのです。 

Rust はまた、現代的な開発ツールをシステムプログラミング世界に導入します。 

• Cargo は、付属の依存マネージャ兼ビルドツールで、依存を追加、コンパイル、管理すること 
を楽かつ、 Rust エコシステムを通じて矛盾させません。 

• Rustfmt は開発者の間で矛盾のないコーディングスタイルを保証します。 



導入 


iii 


• Rust Language Server は IDE(Intefrated Development Environment) にコード補完と 

イ ンラインの エラー メッ セージの 統合の源となります。 

これらや他のツールを Rust のエコシステムで使用することで、開発者はシステムレベルのコード 
を記述しつつ、生産的になれます。 

学生 

Rust は、学生やシステムの概念を学ぶことに興味のある方向けです。 Rust を使用して、多くの人 
が OS 開発などの話題を学んできました。コミュニティはとても暖かく、喜んで学生の質問に答えて 
くれます。この本のような努力を通じて、 Rust チームはシステムの概念を多くの人、特にプログラミ 
ング初心者にとってアクセス可能にしたいと考えています。 

企業 

数百の企業が、大企業、中小企業を問わず、様々なタスクにプロダクションで Rust を使用してい 
ます。そのタスクには、コマンドラインツール、 Web サービス、 DevOps ツール、組み込みデバイ 
ス、オーディオとビデオの解析および変換、暗号通貨、生物情報学、サーチェンジン、 IoT アプリケー 
ション、機械学習、 Firefox ウェブブラウザの主要部分さえ含まれます。 

オープン ソース 開発者 

Rust は、 Rust プログラミング言語やコミュニティ、開発者ツール、ライブラリを開発したい方向 
けです。あなたが Rust 言語に貢献されることを心よりお待ちしております。 

スピードと安定性に価値を見出す方 

Rust は、スピードと安定性を言語に渴望する方向けです。ここでいうスピードとは、 Rust で作れ 
るプログラムのスピードとソースコードを書くスピードのことです。 Rust コン パイ ラのチェックに 
より、機能の追加とリファクタリングを通して安定性を保証してくれます。これはこのようなチェッ 
クがない言語の脆いレガシーコードとは対照的で、その場合開発者はしばしば、変更するのを恐れて 
しまいます。ゼロコスト抽象化を志向し、手で書いたコードと同等の速度を誇る低 レベル コードにコ 
ン パイル される高 レベル 機能により、 Rust は安全なコードを高速なコードにもしようと努力してい 
ます。 

Rust 言語は他の多くのユーザのサポートも望んでいます；ここで名前を出した方は、ただの最大の 
出資者の一部です。総合すると、 Rust の最大の野望は、プログラマが数十年間受け入れてきた代償を 
排除することです：つまり、安全性と生産性、スピードとエルゴノミクスです。 Rust を試してみて、 
その選択が自分に合っているか確かめてください。 
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この本は誰のためのものなの 

この本は、あなたが他のプログラミング言語でコードを書いたことがあることを想定していますが、 
具体的にどの言語かという想定はしません。私たちは、幅広い分野のプログラミング背景からの人に 
とってこの資料を広くアクセスできるようにしようとしてきました。プログラミングとはなんなのか 
やそれについて考える方法について多くを語るつもりはありません。もし、完全なプログラミング初 
心者であれば、プログラミング入門を特に行う本を読むことでよりよく役に立つでしょう。 

この本の使い方 

一般的に、この本は、順番に読み進めていくことを前提にしています。後の章は、前の章の概念の 
上に成り立ち、前の章では、ある話題にさほど深入りしない可能性があります；典型的に後ほどの章 
で同じ話題を再度しています。 

この本には2種類の章があるとわかるでしょう：概念の章とプロジヱクトの章です。概念の章では、 
Rust の一面を学ぶでしょう。プロジェクトの章では、それまでに学んだことを適用して一緒に小さ 
なプログラムを構築します。2、12、20章がプロジェクトの章です。つまり、残りは概念の章です。 

第1章は Rust のインストール方法、 Hello , world ! プログラムの書き方、 Rust のパッケージマ 
ネージャ兼、ビルドツールの Cargo の使用方法を説明します。第2章は、 Rust 言語への実践的な導 
入です。概念を高度に講義し、後ほどの章で追加の詳細を提供します。今すぐ Rust の世界に飛び込み 
たいなら、第2章こそがそのためのものです。第3章は他のプログラミング言語の機能に似た Rust 
の機能を講義していますが、最初その3章すら飛ばして、まっすぐに第4章に向かい、 Rust の所有 
権 システム について学びたくなる可能性があります。しかしながら、あなたが次に進む前に全ての詳 
細を学ぶことを好む特別に几帳面な学習者なら、第2章を飛ばして真っ先に第3章に行き、学んだ詳 
細を適用するプロジェクトに取り組みたくなった時に第2章に戻りたくなる可能性があります。 

第5章は、構造体とメソッドについて議論し、第6章は enuiTl 、 match 式、 if let フロー制御構 
文を講義します。構造体と enum を使用して Rust において独自の型を作成します。 

第7章では、 Rust のモジュールシステムと自分のコードとその公開された API(Application 
Programming Interface ) を体系化するプライバシー規則について学びます。第8章では、ベクタ、 
文字列、ハッシュマップなどの標準ライブラリが提供する一般的なコレクションデータ構造の一部を 
議論します。第9章では、 Rust のエラー処理哲学とテクニックを探究します。 

第10章ではジェネリクス、トレイト、ライフタイムについて深入りし、これらは複数の型に適用 
されるコードを定義する力をくれます。第11章は、完全にテストに関してで、 Rust の安全性保証が 
あってさえ、プログラムのロジックが正しいことを保証するために、必要になります。第12章では、 
ファイル内のテキストを検索する grep コマンドラインツールの一部の機能を自身で構築します。こ 
のために、以前の章で議論した多くの概念を使用します。 

第13章はクロージャとイテレータを探究します。これらは、関数型プログラミング言語由来の 
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Rust の機能です。第 14 章では、 Cargo をより詳しく調査し、他人と自分のライブラリを共有する最 
善の策について語ります。第 15 章では、標準ライブラリが提供するスマートポインタとその機能を 
可能にするトレイトを議論します。 

第 16 章では、並行プログラミングの異なるモデルを見ていき、 Rust が恐れなしに複数のスレッド 
でプログラムする手助けをする方法を語ります。第 17 章では、馴染み深い可能性のあるオブジェク 
卜指向プログラミングの原則と Rust のイディオムがどう比較されるかに目を向けます。 

第 18 章は、パターンとパターンマッチングのリファレンスであり、これらは Rust プログラムを 
通して、考えを表現する強力な方法になります。第 19 章は、 unsafe Rust やライフタイム、トレイ 
卜、型、関数、クロージャの詳細を含む、興味のある高度な話題のスモーガスボード（訳注：日本でい 
うバイキングのこと）を含みます。 

第 20 章では、低レベルなマルチスレッドの' Web サーバを実装するプロジェクトを完成させます！ 

最後に、言語についての有用な情報をよりリファレンスのような形式で含む付録があります。付録 
A は Rust のキーワードを講義し、付録 B は、 Rust の演算子と記号、付録 C は、標準ライブラリが 
提供する継承可能なトレイト、付録 D はマクロを講義します。 

この本を読む間違った方法なんてありません：飛ばしたければ、どうぞご自由に！混乱したら、前 
の章に戻らなければならない可能性もあります。ですが、自分に合った方法でどうぞ。 

Rust を学ぶ過程で重要な部分は、 コンパイラが 表示する エラー メッセージを読む方法を学ぶこと 
です：それは動く コードへ と導いてくれます。そのため、各場面で コンパイラが 表示する エラー メッ 
セージとともに、 コ ン パイルで きない コード の例を多く提供します。適当に例を選んで走らせたら、 
コンパイルで きないかもしれないことを知ってください！周りのテキストを読んで実行しようとして 
いる例が エラーになる ことを意図しているのか確認することを確かめてください。ほとんどの 場合、 
コンパイルで きないあらゆる コー ドの正しいバージ ョン へと導きます。 

ソースコード 

この本が生成されるソースファイルは、 GitHub で見つかります。 
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事始め 


Rust の旅を始めましょう！学ぶべきことはたくさんありますが、いかなる旅もどこかから始まり 
ます。この章では、以下のことを議論します： 

• Rust を Linux 、 macOS 、 Windows にインストールする 

• Hello, world !と出力するプログラムを書く 

• cargo という Rust のパッケージマネージャ兼ビルドシステムを使用する 

1.1 インストール 

最初の手順は、 Rust をインストールすることです。 Rust は、 rustup という Rust のバージョンと 
関連するツールを管理するコマンドラインツールを使用して、ダウンロードします。ダウンロードす 
るには、インターネット接続が必要でしょう。 

注釈：なんらかの理由で rustup を使用しないことを好むのなら、 Rust インストールページで、 
他の選択肢をご覧になってください。 

以下の手順で最新の安定版の Rust コンパイラをインストールします。この本の例と出力は全て、 
安定版の Rustl _21_0 を使用しています。 Rust の安定性保証により、現在この本の例でコンパイル 
できるものは、新しいバージョンになってもコンパイルでき続けることを保証します。出力は、バー 
ジョンによって多少異なる可能性があります。 Rust は頻繁にエラーメッセージと警告を改善してい 
るからです。言い換えると、どんな新しいバージョンでもこの手順に従ってインストールした安定版 
なら、この本の内容で想定通りに動くはずです。 



第 1 章事始め 


2 


1.1.1 コマンドライン表記 

この章及び、本を通して、端末で使用するなんらかのコマンドを示すことがあります。読者が 
入力するべき行は、全て$で始まります。$文字を入れる必要はありません；各コマンドの開始 
を示しているだけです。$で始まらない行は、典型的には直前のコマンドの出力を示します。ま 
た、 PowerShell 限定の例は、$ではなく、>を使用します。 

1.1.2 Linux と macOS に rustup をインストールする 

Linux か macOS を使用しているなら、端末を開き、以下のコマンドを入力してください： 


$ curl https://sh.rustup.rs -sSr | sh 


このコマンドはスクリプトをダウンロードし、 rustup ツールのインストールを開始し、 Rust の最 
新の安定版をインストールします。パスワードを求められる可能性があります。インストールがうま 
く行けば、以下の行が出現するでしょう： 

Rust is 1 nsta lied now. Great! 

お好みでご自由にスクリプトをダウンロードし、実行前に調査することもできます。 

イ ンス トール スクリ ブトは、次回のログイ ン 後に Rust を システムの PATH に自動的に追加しま 
す。端末を再起動するのではなく、いますぐに Rust を使用し始めたいのなら、 シェルで 以下のコマ 
ン ドを実行して Rust を システムの PATH に手動で追加します： 


$ source $HOME/.cargo/env 


また、以下の行を 7. bash_profile に追加することもできます： 

$ export PATH="$HOME/.cargo/bin:$PATH" 

さらに、なんらかの類のリンカが必要になるでしょう。既にインストールされている可能性が高い 
ものの、 Rust プログラムのコンパイルを試みて、リンカが実行できないというエラーが出たら、シ 
ステムにリンカがインストールされていないということなので、手動でインストールする必要がある 
でしょう。 C コンパイラは通常正しいリンカとセットになっています。自分のプラットフォームの 
ドキュメンテーションを見て C コンパイラのインストール方法を確認してください。一般的な Rust 
パッケージの中には、 C コードに依存し、 C コンパイラが必要になるものもあります。故に今インス 
トールする価値はあるかもしれません。 
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1.1.3 Windows で rustup をインストールする 

Windows では、 https://www_rust-lang_org/install_html に行き、手順に従って Rust をインス 
トールしてください。インストールの途中で、 Visual Studio 2013 以降用の C++ ビルドツールも必 
要になるという旨のメッセージが出るでしょう。ビルドツールを取得する最も簡単な方法は、 Visual 
Studio 2017 用のビルドツールをインストールすることです。ツールは、他のツール及びフレーム 
ワークのセクシヨンにあります。 

これ以降、 cmd . exe と PowerShell の両方で動くコマンドを使用します。特定の違いがあったら、 
どちらを使用すべきか説明します。 

1.1.4 更新及びアンインストール 

rustup 経由で Rust をインストールしたら、最新版への更新は、簡単になります。シェルから、以 
下の更新スクリブトを実行してください： 

$ rustup update 

Rust と rustup をアンインストールするには、シェルから以下のアンインストールスクリブトを実 
行してください： 

$ rustup selr um nsta il 


1.1.5 トラブルシューティング 

Rust が正常にインストールされているか確かめるには、シェルを開いて以下の行を入力してくだ 
さい： 

^ rustc --version 

バージョンナンバー、コミットハッシュ、最新の安定版がリリースされたコミット日時が以下の 
フォーマットで表示されるのを目撃するはずです。 

rustc x.y.z ^abcabcabc yyyy-mm-dd) 

この情報が見れたら、 Rust のインストールに成功しました！この情報が出ず、 Windows を使っ 
ているなら、 Rust が％ path% システム環境変数にあることを確認してください。全て正常で、それで 
も Rust が動かないなら、助力を得られる場所はたくさんあります。最も簡単なのが irc.mozilla.org 
の# rust IRC チャンネルで、 Mibbit を通してアクセスできます。そのアドレスで、助けてくれる他 
の Rustacean (自分たちを呼ぶバカなニックネーム）とチャットできます。他の素晴らしいリソース 
には、 ユーザ • フォーラムと Stack Overflow が含まれます。 
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Rustacean: いらないかもしれない補足です。 Rustacean は公式に crustaceans (甲殼類）か 
ら来ているそうです。そのため、 Rust のマスコットは非公式らしいですが、カニ。上の会話で 
C の欠点を削ぎ落としているから c を省いてるの？みたいなことを聞いていますが、違うそう 
です。検索したら、堅牢性が高いから甲殼類という意見もありますが、真偽は不明です。明日 
使えるかもしれないトリビアでした。 

1.1.6 口ーカルのドキュメンテーション 

インストーラは、ドキュメンテーションの複製もローカルに含んでいるので、オフラインで閲覧す 
ることができます。ブラウザでローカルのドキュメンテーションを開くには 、 rustup doc を実行して 
ください。 

標準ライブラリにより型や関数が提供され、それがなんなのかや使用方法に確信が持てない度に、 
API ドキュメンテーションを使用して探してください！ 

1.2 Hello , World ! 

Rust をインストールしたので、最初の Rust プログラムを書きましょう。新しい言語を学ぶ際に、 
Hello , world ! というテキストを画面に出力する小さなプログラムを書くことは伝統的なことなの 
で、ここでも同じようにしましょう！ 

注釈：この本は、コマンドラインに基礎的な馴染みがあることを前提にしています。 Rust は、 
編集やツール、どこにコードがあるかについて特定の要求をしないので、コマンドラインでは 
なく IDE を使用することを好むのなら、どうぞご自由にお気に入りの IDE を使用してくださ 
い。今では、多くの IDE がなんらかの形で Rust をサポートしています；詳しくは、 IDE のド 
キュメンテーションをご覧ください。最近、 Rust チームは優れた IDE サポートを有効にする 
ことに注力し、その前線で急激に成果があがっています！ 


1.2.1 プロジェクトのディレクトリを作成する 

Rust コードを格納するディレクトリを作ることから始めましょう。 RusU ことって、コードがどこ 
にあるかは問題ではありませんが、この本の練習とプロジェクトのために、ホームディレクトリに 
projects ディレクトリを作成してプロジェクトを全てそこに保管することを推奨します。 

端末を開いて以下のコマンドを入力し、 projects ディレクトリと、 projects ディレクトリ内に 
Hello, world! プロジェクトのディレクトリを作成してください。 

Linux と macOS なら、こう入力してください： 


$ mkdir -/projects 
$ cd 〜 /proiects 
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$ mkch r hello_world 
$ cd hello_world 

Windows の cmd なら、こう： 

> mkdir "% USERPROFILE 96\ projects n 

> cd /d "% USERPROFILE %\ projects " 

> mkdir hello_world 

> cd hello_world 

Windows の PowerShell なら、こう： 

> mkdir $ env : USERPROFILE\projects 

> cd $ env : USERPROFILE\projects 

> mkdir hello_world 

> cd hello_world 

1.2.2 Rust プログラムを書いて走らせる 

次にソースファイルを作り、 main.rs と呼んでください。 Rust のファイルは常に .rs という拡張 
子で終わります。ファイル名に2単語以上使っているなら、アンダースコアで区切ってください。例 

えば、 helloworld.rs ではなく、 hello _ world.rs を使用してください。 

さて、作ったばかりの main.rs ファイルを開き、リスト 1-1 のコードを入力してください。 

ファイル名： main.rs 

fn mann () { 

// 世界よ、こんにちは 
println ! (" Hello , world !’ 1 ); 

} 

リスト 1-1： Hello , world ! と出力するプログラム 

ファイルを保存し、端末ウィンドウに戻ってください。 Linux か macOS なら、以下のコマンドを 
打ってファイルをコンパイルし、実行してください： 

$ rustc main.rs 
$ ./main 
Hello , world ! 

Windows なら、. /main の代わりに. \mai n • exe と打ちます： 

> rustc main.rs 

> .\ main.exe 
Hello , world ! 
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0 S に関わらず、 Hello , world ! という文字列が端末に出力されるはずです。この出力が見れない 
なら、「トラブルシューティング」節に立ち戻って、助けを得る方法を参照してください。 

HeUo , world ! が確かに出力されたら、おめでとうございます！正式に Rust プログラムを書きま 
した。 Rust プログラマになったのです！ようこそ！ 

1.2.3 Rust プログラムの解剖 

Hello , world ! プログラムでちょうど何が起こったのか詳しく確認しましょう。こちらがパズルの 
最初のピースです： 

fn mann () { 

} 

これらの行で Rust で関数を定義しています。 main 関数は特別です：常に全ての実行可能な Rust 
プログラムで走る最初のコードになります。 1 行目は、引数がなく、何も返さない main という関数を 
宣言しています。引数があるなら、かっこ （（）） の内部に入ります。 

また、関数の本体が波括弧“})に包まれていることにも注目してください。 Rust では、全ての関 
数本体の周りにこれらが必要になります。 スペースを 1つあけて、開き波括弧を関数宣言と同じ行に 
配置するのがいい ス タイルです。 

これを執筆している時点では、 rustfmt と呼ばれる自動整形ツールは開発中です。複数の Rust プ 
ロジヱクトに渡って、標準的なスタイルに固執したいなら、 rustfmt は特定のスタイルにコードを整 
形してくれます。 Rust チームは、最終的に rustc のように標準的な Rust の配布にこのツールを含む 
ことを計画しています。従って、この本を読んだ時期によっては、既にコンピュータにインストール 
されている可能性もあります！詳細は、オンラインのドキュメンテーションを確認してください。 

main 関数内には、こんなコードがあります： 

println ! (" Hello , world !"); 

この行が、この小さなプログラムの全作業をしています：テキストを画面に出力するのです。ここ 
で気付くべき重要な詳細が4つあります。まず、 Rust のスタイルは、タブではなく、4スペースでイ 
ンデントするということです。 

2 畨目に println ! は Rust のマクロを呼び出すということです。代わりに関数を呼んでいたら、 
println (! なし）と入力されているでしょう。 Rust のマクロについて詳しくは、付録 D で議論しま 
す。とりあえず、！を使用すると、普通の関数ではなくマクロを呼んでいるのだということを知って 
おくだけでいいでしょう。 

3畨目に、 " Hello , world !" 文字列が見えます。この文字列を引数として println !に渡し、この文 
字列が画面に表示されているのです。 

4香目にこの行をセミコロン （；） で終え、この式が終わり、次の式の準備ができていると示唆して 
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いることです 。 Rust コードの ほとんどの行は、 セミコロンで 終わります。 

1.2.4 コンパイルと実行は個別のステップ 

新しく作成したプログラムをちょうど実行したので、その途中の手順を調査しましょう。 

Rust プログラムを実行する前に、以下のように、 rustc コマンドを入力し、ソースファイルの名前 
を渡すことで、 Rust コンパイラを使用してコンパイルしなければなりません。 

5 rustc main.rs 

あなたに C や C++ の背景があるなら、これは gcc や clang と似ていると気付くでしょう。コンパ 
イルに成功後、 Rust はバイナリの実行可能ファイルを出力します。 

Linux 、 macOS 、 Windows の PowerShell なら、 シェルで 以下の よ うに is コマンド を入力する 
ことで実行可能ファイルを見られます： 

$ Is 

man n man n. rs 


Windows の CMD なら、以下のように入力するでしょう： 


> dir /B 96 = the /B option says to only show the file names =96 

%= /B オプションは、ファイル名だけを表示することを宣言する =% 

main.exe 
main.pdb 
man n.rs 


これは、 . rs 拡張子のソースコードファイル、実行可能ファイル （ Windows なら main . exe 、 他 
のプラットフォームでは、 main )、 そして、 CMD を使用しているなら、 . pdb 拡張子のデバッグ情報 
を含むファイルを表示します。ここから、 main か main . exe を走らせます。このように： 

$ ./main # or .\main.exe on Windows 

# または、 Widnows なら . \main.exe 

main . rs が Hello , world ! プログラムなら、この行は Hello, world! と端末に出力するでしょう。 

Ruby や Python 、 JavaScript などの動的言語により造詣が深いなら、プログラムのコンパイルと 
実行を個別の手順で行うことに慣れていない可能性があります。 Rust は AOT コンパイル ( ahead - 
of - time ; 訳注： 予め）言語です。つまり、プログラムをコンパイルし、実行可能ファイルを誰かにあ 
げ、あげた人が Rust をインストールしていなくても実行できるわけです。誰かに . rb 、. py 、. js ファ 
イルをあげたら、それぞれ Ruby 、 Python 、 JavaScript の実装がインストールされている必要があ 
ります。ですが、そのような言語では、プログラムをコンパイルし実行するには、1コマンドしか必 
要ないのです。全ては言語設計においてトレードオフなのです。 

簡単なプログラムなら rustc でコンパイルするだけでも十分ですが、プロジヱクトが月巴大化してく 
ると、オプションを全て管理し、自分のコードを簡単に共有したくなるでしょう。次は、 Cargo ツー 



第 1 章事始め 


8 


ルを紹介します。これは、現実世界の Rust プログラムを書く手助けをしてくれるでしょう。 

1.3 Hello , Cargo ! 

Cargo は、 Rust のビルドシステム兼、パッケージマネージャです。ほとんどの Rustacean はこの 
ツールを 使用して、 Rust プロジェクトの管理をしています。 Cargo は、コードのビルドやコードが 
依存しているライブラリのダウンロード、それらのライブラリのビルド（コードが必要とするライブ 
ラリを我々は、依存と呼んでいます）などの多くの仕事を扱ってくれるからです。 

今までに書いたような最も単純な Rust プログラムは、依存がありません。従って、 Hello,world! 
プロジェクトを Cargo を使ってビルドしても、 Cargo のコードをビルドする部分しか使用しないで 
しょう。より複雑な Rust プログラムを書くにつれて、依存を追加し、 Cargo でプロジェクトを開始 
したら、依存の追加は、遥かに簡単になるのです。 

Rust プロジェクトの大多数が Cargo を使用しているので、これ以降この本では、あなたも Cargo 
を使用していることを想定します。 Cargo は、「インストール」節で議論した公式のインストーラを 
使用していれば、勝手にインストールされます。 Rust を他の何らかの手段でインストールした場合、 
以下の コマン ドを端末に入れて Cargo がイ ン ストールされているか確かめてください： 

$ cargo --version 

バージョンナンバーが見えたら、インストールされています！ command not found などのエラーが 
見えたら、自分のインストール方法を求めてドキュメンテーションを見、 Cargo を個別にインストー 
ルする方法を決定してください。 

1.3.1 Cargo でプロジェクトを作成する 

Cargo を使用して新しいプロジェクトを作成し、元の Hello, world! プロジェクトとどう違うかを 
見ましょう。 projects ディレクトリ（あるいはコードを格納すると決めた場所）に戻ってください。 
それから、 0 S に関わらず、以下を実行してください： 

$ cargo new heLlo_cargo --bin 
$ cd hello_cargo 

最初のコマンドは、 hello_cargo という新しいバイナリの実行可能ファイルを作成します。 cargo 
new に渡した- -bin 引数が、ライブラリとは対照的に実行可能なアプリケーション（よく単にバイナ 
リと呼ばれる）を作成します。プロジェクトを hello_cargo と名付け、 Cargo は、そのファイルを 
同名のディレクトリに作成します。 

hello_cargo ディレクトリに行き、ファイルを列挙してください。 Cargo が 2 つのファイルと 1 
つのディレクトリを生成してくれたことがわかるでしょう： Cargo.toml ファイルと、中に main.rs 
ファイルがある src ディレクトリです。また、 .gitignore ファイルと共に、新しい Git リポジトリ 
も初期化しています。 
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注釈： Git は一般的なバージョンコントロールシステムです 。 cargo new を変更して、異なる 
バージョンコントロールシステムを使用したり、 一 VCS フラグを使用して何もバージョンコン 
トロールシステムを使用しないようにもできます 。 cargo new -- help を走らせて、利用可能 
なオプションを確認してください。 

お好きなテキストエディタで Cargo.toml を開いてください。リスト 1-2 のコードのような見た 
目のはずです。 

ファイル名： Cargo.toml 

[ package ] 

name = " hello _ cargo " 
version = "0.1.0" 

authors = ["Your Name < you @ example . com >"] 

[ dependencies ] 

リスト 1-2: cargo new で生成される Cargo.toml の中身 


この ファイルは TOML ( Tom’s Obvious , Minimal Language ; 直訳：トムの明確な最小限の言 
語） フォーマッ トで、 Cargo の設定 フォーマッ トです。 

最初の行の [ package ] は、後の文がパッケージを設定していることを示すセクションヘッダーで 
す。もっと情報を追加するにつれて、別のセクションも追加するでしょう。 

その後の 3 行が、 Cargo がプログラムをコンパイルするのに必要な設定情報をセットします：名 
前、バージョン、誰が書いたかです。 Cargo は名前と E メールの情報を環境から取得するので、その 
情報が正しくなければ、今修正してそれから保存してください。 

最後の行の [ dependencies ] は、プロジヱクトの依存を列挙するためのセクションの始まりです。 
Rust では、パッケージのコードはクレートとして参照されます。このプロジェクトでは何も他のク 
レートは必要ありませんが、第2章の最初のプロジェクトでは必要なので、その時にはこの依存セク 
ションを使用するでしょう。 

では、 src / main.rs を開いて靦いてみてください： 

フアイル名： src/main.rs 
fn mann () { 

println ! (" Hello , world !"); 

} 

ちょうどリスト 1-1 で書いたように、 Cargo は Hello, world! プログラムを生成してくれていま 
す。ここまでで、前のプロジェクトと Cargo が生成したプロジェクトの違いは、 Cargo が src ディ 
レクトリにコードを配置し、最上位のディレクトリに Cargo.toml 設定ファイルがあることです。 

Cargo は、ソースファイルが src ディレクトリにあることを期待します。プロジェクトの最上位の 
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ディレクトリは、 README ファイル、ライセンス情報、設定ファイル、あるいは、他のコードに関 
連しないもののためのものです。 Cargo を使用すると、プロジェクトを体系化する手助けをしてくれ 
ます。適材適所であり、全てがその場所にあるのです。 

Hello , world ! プロジェクトのように、 Cargo を使用しないプロジェクトを開始したら、実際に 
Cargo を使用するプロジェクトに変換することができます。プロジェクトのコードを src ディレクト 
リに移動し、適切な Cargo.toml ファイルを作成してください。 

1.3.2 Cargo プロジェクトをビルドし、実行する 

さて、 Cargo で Hello , world ! プログラムをビルドし、実行する時の違いに目を向けましょう！ 
hello_cargo ディレクトリから、以下のコマンドを入力してプロジェクトをビルドしてください： 

$ cargo build 

Compiling hello_cargo v 0.1.0 (ri ie :/// pro ] ects / hello _ cargo ) 

Finished dev [unoptimized + debuginfo] target(s) in 2.85 secs 

このコマンドは、カレントディレクトリではなく、 target/debug/hello_cargo (あるいは 
Windows なら、 target/debug/hello_cargo.exe) に実行可能ファイルを作成します。以下のコ 
マンドで実行可能ファイルを実行できます： 

$ ./ target / debug / he l io_cargo # or .\ target \ debug \ hello _ cargo.exe on Windows 

# あるいは、 Windows なら、 .\target\debug\hello_cargo 
.exe 

Hello, world! 

全てがうまくいけば、 Hello, world ! が端末に出力されるはずです。初めて cargo build を実行 
すると、 Cargo が最上位に新しいファイルも作成します： Cargo.lock です。このファイルは、自分 
のプロジェクトの依存の正確なバージョンを追いかけます。このプロジェクトには依存がないので、 
ファイルはやや空っぽです。絶対にこのファイルを手動で変更する必要はないでしょう； Cargo が中 
身を管理してくれるのです。 

cargo build でプロジヱクトをビルドし、 • /target/debug/helAo_cargo で実行したばかりですが、 
cargo run を使用して、コードをコンパイルし、それから吐かれた実行可能ファイルを全部 1 コマン 
ドで実行することもできます： 

$ cargo run 

Finished dev [unoptimized + debuginfo 」 target ( s)in 0.0 secs 
Running ' target / debug / hello _ cargo ' 

Hello, world! 


今回は、 Cargo が heUo_cargo をコンパイルしていることを示唆する出力がないことに気付いて 
ください。 Cargo はファイルが変更されていないことを推察したので、単純にバイナリを実行したの 
です。ソースコードを変更していたら、 Cargo は実行前にプロジェクトを再ビルドし、こんな出力を 
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目の当たりにしたでしよう： 

$ cargo run 

Compiling hello_cargo v 0.1.0 (ti ie :/// pro ] ects / hello _ cargo ) 

Finished dev [unoptimized + debuginfo ] target ( s ) in 0.33 secs 
Running ' target / debug / hello _ cargo ' 

Hello , world ! 

Cargo は cargo check というコマンドも提供しています。このコマンドは、迅速にコードを確認 
し、コンパイルできることを確かめますが、実行可能ファイルは生成しません： 

$ cargo check 

Compiling hello_cargo v 0.1.0 (ti ie :/// pro ] ects / hello _ cargo ) 

Finished dev [unoptimized + debuginfo ] target ( s ) in 0.32 secs 

何故、実行可能ファイルが欲しくないのでしようか？しばしば、 cargo check は、 cargo build 
よりも遥かに速くなります。実行可能ファイルを生成する手順を飛ばすからです。コードを書いて 
いる際に継続的に自分の作業を確認するのなら、 cargo check を使用すると、その過程が高速化さ 
れます！そのため、多くの Rustacean は、プログラムを書く際にコンパイルできるか確かめるた 
めに定期的に cargo check を実行します。そして、実行可能ファイルを使用できる状態になったら、 
cargo build を走らせるのです。 

ここまでに Cargo について学んだことをおさらいしましよう： 

• cargo build か cargo check でプロジェクトをビルドできる。 

• プロジェクトのビルドと実行を 1 ステップ、 cargo run でできる。 

• ビルドの結果をコードと同じディレクトリに保存するのではなく、 Cargo は target/debug 

ディレクトリに格納する。 

Cargo を使用する追加の利点は、使用している 0 S に関わらず、同じコマンドが使用できることで 
す。故にこの時点で、 Windows と Linux 及び macOS で特定の手順を提供することは最早なくな 
ります。 

1.3.3 リリースビルドを行う 

プロジェクトを最終的にリリースする準備ができたら、 cargo build --release を使用して、 
最適化を行なってコンパイルすることができます。このコマンドは、 target/debug ではなく、 
target/release に実行可能ファイルを作成します。最適化は、 Rust コードの実行を速くしてくれま 
すが、オンにするとプログラムをコンパイルする時間が延びます。このため、2つの異なるプロファ 
イルがあるのです：頻繁に再ビルドをかけたい開発用と、繰り返し再ビルドすることはなく、できる 
だけ高速に動いてユーザにあげる最終的なプログラムをビルドする用です。コードの実行時間をベン 
チマークするなら、 cargo build --release を確実に実行し、 target/release の実行可能ファイル 
でベンチマークしてください。 
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1.3.4 習慣としての Cargo 


単純なプロジェクトでは、 Cargo は単に rustc を使用する以上の価値を生みませんが、プログラム 
が複雑になるにつれて、その価値を証明するでしょう。複数のクレートからなる複雑なプロジェクト 
では、 Cargo にビルドを調整してもらうのが遥かに簡単です。 

heUo_cargo プロジェクトは単純ではありますが、今では、 Rust のキャリアを通じて使用するであ 
ろう本物の ツールを 多く使用するようになりました。事実、既存のどんなプロジェクトに取り組むに 
も、以下の コマンドを 使用して、 Git で コードを チェックアウトし、そのプロジェクトのディレクト 
リに移動し、ビルドできます： 

$ git cLone someurl . com/someproject 
$ cd someproiect 
$ cargo build 

Cargo についてより詳しく知るには、ドキユメンテーシヨンを確認してください。 

1.4 まとめ 

既に Rust の旅の素晴らしいスタートを切っています！この章では、以下の方法を学びました： 

• rustup で最新の安定版の Rust をインストールする方法 
• 新しい Rust のバージヨンに更新する方法 

• ローカルにインストールされたドキユメンテーシヨンを 開く方法 

• 直接 rustc を使用して Hello , world ! プログラムを書き、実行する方法 

• Cargo の慣習を使用して新しいプロジェクトを作成し、実行する方法 

より中身のあるプログラムをビルドし、 Rust コードの読み書きに慣れるいいタイミングです。故 
に、第2章では、数当てゲームを構築します。むしろ一般的なプログラミングの概念が Rust でどう 
動くのか学ぶことから始めたいのであれば、第3章を見て、それから第2章に戻ってください。 
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2； 


数当てゲームをプログラムする 


実物のプロジヱタトに一緒に取り組むことで、 Rust の世界へ飛び込みましょう！この章では、実 
際のプログラム内で使用しながらいくつかの一般的な Rust の概念に触れます。 let 、 match 、 メソッ 
ド、関連関数、外部クレートの使用などについて学ぶでしょう！後ほどの章でこれらの概念について 
深く知ることになります。この章では、基礎部分だけにしましょう。 

古典的な初心者向けのプログラミング問題を実装してみましょう：数当てゲームです。これは以下 
のように動作します：プログラムは1から100までの乱数整数を生成します。そしてプレーヤーに予 
想を入力するよう促します。予想を入力したら、プログラムは、その予想が小さすぎたか大きすぎた 
かを出力します。予想が当たっていれば、ゲームは祝福メッセージを表示し、終了します。 

2.1 新規プロジェクトの立ち上げ 

新規プロジェクトを立ち上げるには、第 1 章で作成した projects ディレクトリに行き、 Cargo を 
使って新規プロジェクトを作成します。以下のように： 

$ cargo new guessing_game --bin 
$ cd guessing_game 


最初のコマンド cargo new は、プロジヱクト名を第1引数に取ります ( guessing _ game ですね)〇 
- bin というフラグは、 Cargo にバイナリ生成プロジェクトを作成させます。第 1 章のものと似てい 
ますね。2番目のコマンドで新規プロジェクトのディレクトリに移動します。 

生成された Cargo.toml ファイルを見てください： 

ファイル名： Cargo.toml 


[ package ] 

name = " guessing _ game " 
version = "0.1.0" 
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authors = [" 名刖 <vou@exampLe.com>"] 

[dependencies 」 

もし、 Cargo があなたの環境から取得した作者情報が間違っていたら、ファイルを編集して保存し 
直してください。 

第 1 章でも見かけたように、 cargo new コマンドは、 ’’ Hello , world !” プログラムを生成してくれ 
ます。 src/main.rs ファイルをチェックしてみましょう： 

フアイル名： src / main.rs 

fn mann() { 

println ! (" Hello , world !"); 

} 

さて、この’’ Hello , world !” プログラムをコンパイルし、 cargo run コマンドを使用して、以前と 
同じように動かしてみましょう： 

$ cargo run 

Compiling guessing_game v0.1.0 げ iLe:///pro]ects/guessing_game) 

Finished dev [unoptimized + debuginfo] target(s) in 1.50 secs 
Running 'target/debug/guessing_game' 

Hello, world! 

run コマンドは、プロジニクトに迅速に段階を踏んで取り掛かる必要がある場合に有用であり、次 
のステップに進む前に各段階を急速にテストして、このゲームではそれを行います。 

再度 src/main.rs ファイルを開きましょう。ここにすベてのコードを書いていきます。 

2.2 予想を処理する 

数当てプログラムの最初の部分は、ユーザに入力を求め、その入力を処理し、予期した形式になっ 
ていることを確認します。手始めに、プレーヤーが予想を入力できるようにしましょう。リスト 2-1 
のコードを src/main.rs に入力してください。 

フアイル名： src / main.rs 
use std :: io; 
fn mann() { 

println! ("Guess the number!"); 
println! ("Please input your* guess."); 
let mut guess = Stri ng: : new(); 


// 数を当ててごらん 
// ほら、予想を入力してね 
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1 〇:: stdin (). read _ line(&mut guess ) 

.expect ("Failed to read line 11 ); // 行の読み込みに失敗しました 

println ! ("You guessed : {}" , guess ); // 次のように予想しました ： {} 

} 


リスト 2-1: ユーザに予想を入力してもらい、それを出力するコード 


注釈： The programming language Rust 第 1 版の翻訳者によると、 ソースコードのコメン 
卜 中以外に日本語文字があると コ ンパイ ルに 失敗することがあるそうなので、文字列の英語は、 
コメントに 和訳を載せます。また、重複する内容の場合には、最初の1回だけ掲載するように 
します。 


このコードには、たくさんの情報が詰め込まれていますね。なので、行ごとに見ていきましょう。 
ユーザ入力を受け付け、結果を出力するためには 、 io (入/出力）ライブラリをスコープに導入する必 
要があります。 io ライブラリは、標準ライブラリ （ std として知られています）に存在します： 

use std :: io ; 

デフォルトでは、 prelude に存在するいくつかの型のみ使えます。もし、使用したい型が prelude 
にない場合は、 use 文で明示的にその型をスコープに導入する必要があります。 std : : io ライブラリを 
使用することで、ユーザ入力を受け付ける能力などの実用的な機能の多くを使用することができます。 

第1章で見た通り、 main 関数がプログラムへのエントリーポイント（脚注：スタート地点）になり 
ます： 

fn mann () { 

fn 構文が関数を新しく宣言し、かっこの （） は引数がないことを示し、波括弧の{が関数本体のス 
タート地点になります。 

また、第1章で学んだように、 pHntln ! は、文字列を画面に表示するマクロになります： 
onntln ! ("Guess the number ! 11 ); 
println! ("Please input your guess ."); 

このコードは、このゲームが 何かを出力し、 ユーザに 入力を求めています。 

2.2.1 値を変数に保持する 

次に、 ユーザ 入力を保持する場所を作りましょう。こんな感じに： 
let mut guess = Stn ng : : new (); 
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さあ、プログラムが面白くなってきましたね。このたった1行でいろんなことが起きています。こ 
れが let 文であることに注目してください。これを使用して変数を生成しています。こちらは、別の 
例です： 


Let foo = bar: 

この 行では、 foo という名前の新しい変数を作成し、 bar の値に束縛しています。 Rust では、変数 
は標準で不変 （immutable) です。 この 概念について詳しくは、第 3 章の「変数と可変性」節で議論 
します。以下の例には、変数名の前に mut をつけて変数を可変にする方法が示されています： 

Let foo = 5; // immutable 
Let mut bar = 5; // mutable 


注釈：//という記法は、行末まで続くコメントを記述します。コンパイラは、コメントを一切 
無視し、これについても第3章で詳しく議論します。 

数 当てゲームのプログラムに 戻りましょう。さあ、 i et mut g uess が g uess という名前の可変変数 
を導入するとわかりましたね。イ コール 記号 （=) の反対側には、変数 guess が束縛される値がありま 
す。この値は、 String : : new 関数の呼び出し結果であり、この関数は 、 Stri ng 型のオブジヱクトを返 
します。 String 型は、標準ライブラリ によって 提供される文字列型で、サイズ可変、 UTF -8 エン コー 
ドされたテキスト破片になります。 

:: new 行にある：：という記法は、 new が String 型の関連関数であることを表しています。関連関 
数とは、 String 型の特定のオブジェクトよりも型（この場合は String ) に対して実装された関数のこ 
とであり、静的（スタティック）メソッドと呼ばれる言語もあります。 

この new 関数は、新しく空の文字列を生成します。 new 関数は、いろんな型に見られます。なぜな 
ら、何らかの新規値を生成する関数にとってありふれた名前だからです。 

まとめると 、 let mut guess = String : : new (); という行は、現在、新たに空の Stri ng オブジェク 
卜に束縛されている可変変数を作っているわけです。ふう！ 

プログラムの1行目で 、 use std :: io として、標準ライブラリから入/出力機能を取り込んだことを 
思い出してください。今度は、彳〇型の stdin 関連関数を呼び出しましょう： 

1 〇:: stdin (). read _ line(&mut guess ) 

. expect("Failed to read nne ") : 

仮に、プログラムの冒頭で use std :: io としていなければ、この関数呼び出しは、 std : : io : : stdin 
と記述していたでしょう。この stdin 関数は、 std : : io : : Stdin オブジェクトを返し、この型は、ター 
ミナルの標準入力へのハンドルを表す型になります。 

その次のコード片、 • read _ line(&mut guess ) は、標準入カハンドルの read_line メソッドを呼び 
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出して、ユーザから入力を受け付けます。また、 read_line メソッドに対して、 &mut guess という引 
数を一つ渡していますね。 

read_line メソッドの仕事は、ユーザが標準入力したものすべてを取り出し、文字列に格納するこ 
となので、格納する文字列を引数として取ります。この文字列引数は、可変である必要があります。 
メソッドがユーザ入力を追記して、文字列の中身を変えられるようにということですね。 

&という記号は、この引数が参照であることを表し、これのおかげで、データを複数回メモリにコ 
ピーせずとも、コードの複数箇所で同じデータにアクセスできるようになるわけです。参照は複雑な 
機能であり、とても安全かつ簡単に参照を使うことができることは、 Rust の主要な利点の一つでもあ 
ります。そのような詳細を知らなくても、このプログラムを完成させることはできます。現時点では、 
変数のように、参照も標準で不変であることを知っておけばいいでしょう。故に、 &guess と書くので 
はなく、 &mut guess と書いて、可変にする必要があるのです。（第 4 章で参照についてより詳細に説 
明します） 


2.2.2 Result 型で失敗の可能性を扱う 

まだ、この行は終わりではありませんよ。ここまでに議論したのはテキストでは1行ですが、コー 
ドとしての論理行としては、まだ所詮最初の部分でしかないのです。2番目の部分はこのメソッド 
です： 

. expect("Failed to read line "); 

. foo () という記法で、メソッドを呼び出す時、改行と空白で長い行を分割するのがしばしば賢明で 
す。今回の場合、こう書くこともできますよね： 

1 〇: : stdin () • read _ line(&mut guess ) . expect("Failed to read Line 11 ): 

しかし、長い行は読みづらいものです。なので、分割しましょう： 2回のメソッド呼び出しに、2行 
です。さて、この行が何をしているのかについて議論しましょうか。 

以前にも述べたように、 read_line メソッドは、渡された文字列にユーザが入力したものを入れ込 
むだけでなく、値も返します（今回は io : :Result です)。 Rust には Result と名のついた型が、標準 
ライブラリにたくさんあります：汎用の Result の他、 io : : Result などのサブモジュール用に特化し 
たものまで。 

この Result 型は、列挙型であり、普通、 enum (イーナム）と呼ばれます。列挙型とは、固定され 
た種類の値を持つ型のことであり、それらの値は、 enum の列挙子 （ variant ) と呼ばれます 。 enum 
について は、第6章で詳しく解説します。 

Result 型に関しては、列挙子は Ok か Err です。 Ok 列挙子は、処理が成功したことを表し、中に生 
成された値を保持し ます。 Err 列挙子は、処理が失敗したことを意味し、 Err は、処理が失敗した過程 
や、 理由などの情報を保有し ます。 
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これら Result 型の目的は、エラー処理の情報をコード化することです。 Result 型の値も、他の型 
同様、メソッドが定義されています。 io : : Result オブジェクトには、呼び出し可能な expect メソッ 
ドがあります。この io :: Result オブジヱクトが Err 値の場合 、 expect メソッドはプログラムをク 
ラッシュさせ、引数として渡されたメッセージを表示します 。 reacLline メソッドが Err を返したら、 
恐らく根底にある 0 S によるエラーに起因するのでしょう。この io :: Result オブジェクトが Ok 値の 
場合 、 expect メソッドは、 Ok 列挙子が保持する返り値を取り出して、ただその値を返すので、これ 
を使用することができるでしょう。今回の場合、その返り値とは、ユーザが標準入力に入力したデー 
夕のパイト数になります。 

もし 、 expect メソッドを呼び出さなかったら、コンパイルは通るものの、警告が出るでしょう： 

$ cargo build 

Compiling guessing_game v 0.1.0 ( file :/// Dro ] ects / guessing _ game ) 
warning : unused ' std :: result :: Result ' which must be used 

( 警告：使用されなければならない ' std : : result : : Result ' が使用されていません） 

-- > src / main . rs :10:5 

I 

10 | 1 〇: : stdin ()• read _ line(&mut guess ); 

| 八八八八八八八八八八八八八八八八八八八八八八八八八八八八八八八八八八 

I 

= note : #[ warn ( unused _ must _ use )] on by default 

コンパイラは、私たちが read_line メソッドから返ってきた Result 値を使用していないと警告し 
てきており、これは、プログラムがエラーの可能性に対処していないことを示します。 

警告を抑制する正しい手段は、実際にェラー対処コードを書くことですが、今は、問題が起きた時 
にプロラグムをクラッシュさせたいので、 expect を使用できるわけです。エラーから復旧する方法に 
ついては、第9章で学ぶでしょう。 

2.2.3 println ! マクロのプレースホルダー で 値 を 出力す る 

閉じ波かっこを除けば、ここまでに追加されたコードのうち議論すべきものは、残り1行であり、 
それは以下の通りです： 

onntln ! ("You guessed : {}" . guess ); 

この行は、ユーザ入力を保存した文字列の中身を出力します。1組の波括弧の〇は、プレースホル 
ダーの役目を果たします： {} は値を所定の場所に保持する小さなカニのはさみと考えてください。波 
括弧を使って一つ以上の値を出力できます：最初の波括弧の組は、フォーマット文字列の後に列挙さ 
れた最初の値に対応し、2組目は、2つ目の値、とそんな感じで続いていきます。1回の println ! の 
呼び出しで複数の値を出力するコードは、以下のような感じになります： 

let x = 5; 
let v =10; 
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pn ' ntln!("x = {} and y = {}", x , y ); 

このコードは、 x = 5 and y =10 と出力するでしょう. 

2.2.4 最初の部分をテストする 

数当てゲームの最初の部分をテストしてみましょう。 cargo run でプログラムを走らせてください: 
$ cargo run 

Compiling guessing_game v 0.1.0 げ i (_ e :/// pro ] ects / guessing _ game ) 

Finished dev [unoptimized + debuginfo ] target ( s ) in 2.53 secs 
Running ' target / debug / guessing _ game ' 

Guess the number ! 

Please input your guess . 

6 

You guessed : 6 

ここまでで、ゲームの最初の部分は完成になります：キーボードからの入力を受け付け、出力でき 
ています。 

2.3 秘密の数字を生成する 

次に、ユーザが数当てに挑戦する秘密の数字を生成する必要があります。毎回この秘密の数字は、 
変わるべきです。ゲームが何回も楽しめるようにですね。ゲームが難しくなりすぎないように、1か 
ら100までの乱数を使用しましょう。 Rust の標準ライブラリには、乱数機能はまだ含まれていませ 
ん。ですが、実は、 Rust の開発チームが rand クレートを用意してくれています。 

2.3.1 クレートを使用して機能を追加する 

クレートは Rust コードのパッケージであることを思い出してください。私たちがここまで作って 
きたプロジェクトは、バイナリクレートであり、これは実行可能形式になります。 rand クレートはラ 
イブラリクレートであり、他のプログラムで使用するためのコードが含まれています。 

外部クレートを使用する部分は、 Cargo がとても輝くところです。 rand を使ったコードを書ける 
前に、 Cargo , toml ファイルを編集して、 rand クレートを依存ファイルとして取り込む必要があり 
ます。今このファイルを開いて、以下の行を Cargo が自動生成した [ dependencies ] セクションへッ 
ダの一番下に追記しましょう： 

ファイル名： Cargo.toml 

[ dependencies 」 


rand = "0.3.14 
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Cargo . toml ファイルにおいて、ヘッダに続くものは全て、他のセクションが始まるまで続くセク 
ションの一部になります。 [dependecies] セクションは、プロジヱクトが依存する外部クレートと必 
要とするバージョンを記述するところです。ここでは、 rand クレートで、セマンティックバージョ 
ン指定子には 0.3.14 を指定します。 Cargo は、バージョンナンバー記述の標準規格であるセマン 
ティックバージョニング（時に SemVer と呼ばれる）を理解します。 0 . 3 . 14 という数字は、実際には 
-0.3.14 の省略記法で、これは、「バージョン 0.3.14 と互換性のある公開 API を持つ任意のバージョ 
ン」を意味します。 

さて、コードは一切変えずに、リスト 2-2 のようにプロジェクトをビルドしましょう。 

$ cargo build 

Updating registrv https://github.com/rust-lang/crates.io-index 
を更新しています） 

Downloading rand v0. 3 . 14 

. 3.14 をダウンロー ドしています） 

Downloading nbe v0. 2 . 14 

• 2 •14 をダウンロー ドしています） 

Compiling nbe v0. 2 . 14 

• 2 •14 をコンパイルしています） 

Compiling rand v0. 3 . 14 

• 3 • 14 をコンパイルしています） 

Compiling guessing_game v0. 1 .0 (file:///projects/guessing_game) 
guessi ng_game v0.1.0 をコンノ弋イノレして L ヽます) 

Finished dev [unoptimized + debuginfo] target(s) in 2.53 secs 

リスト 2-2: rand クレートを依存として追加した後の cargo build コマンドの 出力 

もしかしたら、バージョンナンバーは違うかもしれません（でも、互換性はあります、 SemVer の 
おかげでね！）。そして、行の出力順序も違うかもしれません。 

今や、外部依存を持つようになったので、 Cargo はレジストリ （ registry 、 登録所）から最新バー 
ジョンを拾ってきます。レジストリとは、 Crates . io のデータのコピーです。 Crates . io とは 、 Rust 
の エコシステム にいる人間が、他の人が使えるように自分のオープンソースの Rust プロジェクトを 
投稿する場所です。 

レジストリの更新 後、 Cargo は [dependencies] セクションをチェックし、まだ取得していないク 
レートを全部ダウンロードします。今回の 場合 、 rand しか依存ファイルには列挙していませんが、 
Cargo は libc のコピーも拾ってきます。 rand クレートが li ' bc に依存しているからですね。クレー 
卜のダウンロー ド 完了後、 コンパイラは依存ファイルをコンパイルし、依存が利用可能な状態でプロ 
ジェクトをコンパイルします。 

何も変更せず即座に cargo build コマンドを走らせたら、 Finished f 了を除いて何も出力されない 
でしょう。 Cargo は、既に全ての依存をダウンロードしてコンパイル済みであることも、あなたが 
Cargo . toml ファイルを弄ってないことも知っているからです。さらに、 Cargo はプログラマがコー 
ドを変更していないことも検知するので、再度コンパイルすることもありません。することがないの 
で、ただ単に終了します。 


(レジストリ 
(rand v 0 
(libc v 0 
(libc v 0 
(rand v 0 
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src/main.rs ファイルを開き、些細な変更をし、保存して再度ビルドを行えば、2行だけ出力があ 
るでしょう： 

$ cargo build 

Compiling guessing_game v 0.1.0 げ i Le :/// pr * o ] ects / guessing _ game ) 

Finished dev [unoptimized + debuginfo ] target ( s ) in 2.53 secs 

これらの行は、 Cargo が src/main.rs ファイルへの取るに足らない変更に対して、ビルドを更新 
していることを示しています。依存は変更していないので、 Cargo は、既にダウンロードしてコンパ 
イルまで済ませてある依存を使用できると検知します。自分で書いたコードのみ再ビルドをかけるわ 
けです。 

2.3.1.1 Cargo.lock ファイルで再現可能なビルドを保証する 
Cargo は、プログラマが自分のコードを更新するたびに同じ生成物を再構成することを保証して 
くれるメカニズムを備えています： Cargo は、プログラマが示唆するまで、指定したバージョンの依 
存のみを使用します。例として、 rand クレートの次週のバージョン 0.3.15 が登場し、重要なバグ修 
正がなされているけれども、自分のコードを破壊してしまう互換性破壊があった場合はどうなるで 
しょぅ？ 

この問題に対する回答は、 Cargo.lock ファイルであり、このファイルは、初めて cargo build コ 
マンドを走らせた時に生成され、現在 guessing_game ディレクトリに存在しています。プロジェ 
クトを初めてビルドする際に、 Cargo は判断基準 (criteria) に合致するよう全ての依存のバージョ 
ンを計算し、 Cargo.lock ファイルに記述します。次にプロジェクトをビルドする際には、 Cargo は 
Cargo.lock ファイルが存在することを確かめ、再度バージョンの計算の作業を行うのではなく、そ 
こに指定されているバージョンを使用します。このことにより、自動的に再現可能なビルドを構成で 
きるのです。つまり、明示的にアップグレードしない限り、プロジェクトが使用するバージョンは 
0.3.14 に保たれるのです。 Careo.lock ファイルのおかげでね。 

2.3.1.2 クレートを更新して新バージョンを取得する 

ク レート を本当にアップ グレー ドする必要が出てきたら、 Cargo は別の コマンド (update ) を提供 
します。これは、 Cargo.lock ファイルを無視して、 Cargo.toml ファイル内の全ての指定に合致する 
最新バージョンを計算します。それがうまくいったら、 Cargo はそれらのバージョンを Cargo.lock 
ファイルに記述します。 

しかし標準で Cargo は、 0.3.0 より大きく、 0.4.0 未満のバージョンのみを検索します。 rand ク 
レートの新バージョンが2つリリースされていたら （0 • 3 • 15と0 .4 • 0だとします )、 cargo update コ 
マンドを走らせた時に以下のようなメッセージを目の当たりにするでしょう： 


$ cargo update 

Updating registry https :// github . com / rust - Lang / crates . io-index 

( レジストリ、 https : //gi thub . com / rust - lang / crates - io-i ndex ' を更新しています） 

Updating rand v 0.3.14 -> v 0.3.15 
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(rand クレートを V 0.3.14 -> V 0. 3 • 15 に更新しています） 

この時点で、 Cargo.lock ファイルに書かれている現在使用している rand クレートのバージョン 
が、 0.3.15 になっていることにも気付くでしよう。 

rand のバージョン 0.4.0 または、 0.4. x シリーズのどれかを使用したかったら、代わりに 
Cargo, toml フアイルを以下のように更新しなければならないでしょう： 


[ dependencies 」 
rand = "0.4.0" 

次回 、 cargo bund コマンドを走らせたら、 Cargo は利用可能なクレートのレジストリを更新し、 
rand クレートの必要条件を指定した新しいバージョンに従って再評価します。 

まだ第14章で議論する Cargo とその エコシステムに ついては述べたいことが山ほどありますが、 
とりあえずは、これで知っておくべきことは全てです。 Cargo のおかげでライブラリはとても簡単に 
再利用ができるので、 Rustacean は数多くのパッケージから構成された小規模のプロジヱクトを書 
くことができるのです。 

2.3.2 乱数を生成する 

Cargo . toml に rand クレートを追加したので、 rand クレートを使用開始しましょう。次のステッ 
プは、リスト 2-3 のように src / main . rs ファイルを更新することです。 

フアイル名： src / main.rs 

extern crate rand ; 

use std : : io ; 
use rand :: Rng ; 

fn main () { 

println! ("Guess the number ! ") ; 

let secret_number = rand : : thread _ rng (). gen _ range ( l , 101) ; 

pri ntln ! ("The secret number is : {}" , secret _ number ); // 秘密の数字は次の通 

り： {} 

println ! ("Please input your guess ."); 

let mut guess = Stri ng : : new (); 

io :: stdin (). read _ line(&mut guess ) 

. expect ("Failed to read line "); 

println! ("You guessed : {}" , guess ); 

} 
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リスト 2-3: 乱数を生成するコードの追加 


まず、コンパイラに rand クレートを外部依存として使用することを知らせる行を追加しています。 
これにより、 use rand を呼ぶのと同じ効果が得られるので、 rand クレートのものを rand :: という接 
頭辞をつけて呼び出せるようになりました。 

次に、別の use 行を追加しています： use rand : : Rng ですね。 Rng トレイトは乱数生成器が実装す 
るメソッドを定義していて、このトレイトがスコープにないと、メソッドを使用できないのです。卜 
レイトについて詳しくは、第10章で解説します。 

また、途中に2行追加もしています。 rand : : thread_rng 関数は、これから使う特定の乱数生成 
器を返してくれます：この乱数生成器は、実行スレッドに固有で、 OS により、シード値を与えら 
れています。次に、この乱数生成器の gen_range メソッドを呼び出しています。このメソッドは、 
use rand : : Rng 文でスコープに導入した Rng トレイトで定義されています。 gen_range メソッドは二 
つの数字を引数に取り、それらの間の乱数を生成してくれます。範囲は下限値を含み、上限値を含ま 
ないため、 1 と 101 と指定しないと1から100の範囲の数字は得られません。 

注釈：単純に使用すべきトレイトと、クレートからどのメソッドと関数を呼び出すか知って 
いるわけではないでしょう。クレートの使用方法は、各クレートのドキュメントにあります。 
Cargo の別の素晴らしい機能は、 cargo doc --open コマンドを走らせて口ーカルに存在する 
依存すベてのドキュメントをビルドし、ブラウザで閲覧できる機能です。例えば、 rand クレー 
卜の他の機能に興味があるなら、 cargo doc --open コマンドを走らせて、左側のサイドバー 
から rand をクリックしてください。 

コードに追加した2行目は、秘密の数字を出力してくれます。これは、プログラムを開発中にはテ 
ストするのに役立ちますが、最終版からは削除する予定です。プログラムがスタートと同時に答えを 
出力しちゃったら、ゲームになりませんからね！ 

試しに何回かプログラムを走らせてみてください： 

$ cargo run 

Compiling guessing_game v 0.1.0 Le :/// projects / guessing _ game ) 

Finished dev [unoptimized + debuginfo ] target ( s ) in 2.53 secs 
Running ' target / debug / guessing _ game ' 

Guess the number ! ( 何回も出ているので、ここでは和訳は省 

略します） 

The secret number is : 7 

Please input your guess . 

4 

You guessed : 4 

$ cargo run 

Running ' target / debug / guessing _ game ' 

Guess the number ! 

The secret number is : 83 
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PLease inout your guess . 

5 

You guessed : 5 

毎回異なる乱数が出て、その数字はすべて1から100の範囲になるはずです。よくやりました！ 


2.4 予想と秘密の数字を比較する 


今や、ユーザ入力と乱数生成ができるようになったので、比較することができますね。このステッ 
プはリスト 2-4 に示されています。これから説明するように、このコードは現状ではコンパイルでき 
ないことに注意してください。 

フアイル名： src / main.rs 

extern crate rand ; 

use std : : io ; 

use std : : cmp :: Ordering ; 

use rand :: Rng ; 

fn main () { 

// - snip - 

println! ("You guessed : {}" , guess ); 


match guess . cmp (& secret _ number ) { 

Orderi ng: : Less => println! ("Too small ! ") , 
Ordering: : Greater => println! ("Too big ! ") , 
Orderi ng : : Equal => println! ("You win !"), 



//小さすぎ 
// 大きすぎ 
//やったね 


リスト 2-4： 2値比較の可能性のある返り値を処理する 


最初の新しい点は、別の use 文です。これで、 S td :: C mp :: 0 rder*ing という型を標準ライブラリか 
ら スコープに 導入しています。 Result と同じく Ordering も enUTQ です。 ただ 、 Ordering の列挙子 
は、 Less 、 Greater、Equal です。これらは、2値比較した時に発生しうる3種類の結果です。 

match guess . cmp (& secret _ number ) { 

Orderi ng: : Less => println! ("Too small ! ") , 

Ordering: : Greater => println! ("Too big ! ") , 

Orderi ng : : Equal => println! ("You win !"), 

} 


それから、一番下に新しく 5 行追加して Ordering 型を使用しています。 cmp メソッドは、2値を比 
較し、比較できるものに対してなら何に対しても呼び出せます。このメソッドは、比較したいものへ 
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の参照を取ります：ここでは、 guess 変数と secret _ number 変数を比較しています 0 それからこのメ 
ソッドは use 文でスコープに導入した Ordering 列挙型の値を返します。 match 式を使用して 、 guess 
変数と secret _ number を cmp に渡して返ってきた Ordering の列挙子に基づき、次の動作を決定して 
います。 

match 式は、複数のアーム（腕）からできています。一つのアームは、パターンとそのパターンに 
match 式の冒頭で与えた値がマッチした時に走るコードから構成されています。 Rust は、 match に与 
えられた値を取り、各アームのパターンを順番に照合していきます。 match 式とパターンは、コード 
を書く際に出くわす様々なシチュエーシヨンを表現させてくれ、すべてのシチュエーシヨンに対処し 
ていることを保証するのを手助けしてくれる Rust の強力な機能です。これらの機能は、それぞれ、 
第6章と第18章で詳しく講義することにします。 

ここで使われている match 式でどんなことが起こるかの例をじっくり観察してみましょう！例え 
ば、ユーザは50と予想し、ランダム生成された秘密の数字は今回、38だったとしましょう。コード 
が50と38を比較すると 、 cmp メソッドは Orderi ng : : Greater を返します。50は38よりも大きいか 
らですね。 match 式に Ordering : : Greater が与えられ、各アームのパターンを吟味し始めます。まず、 
最初のアームのパターンと照合します （ Ordering : : Less ですね)。しかし、値の Ordering : : Greater 
と Ordering : : Less はマッチしないため、このアームのコードは無視され、次のアームに移ります。次 
のア ー ムのパターン、 0「<^「1'叩：：6「6316「は見寧に0「(^「1'叩：：6「63セ6「 とマッチします！このアー 
ムに紐づけられたコードが実行され、画面に Too big ! が表示されます。これで match 式の実行は終 
わりになります。この筋書きでは、最後のアームと照合する必要はもうないからですね。 

ところが、リスト 2-4 のコードは、まだコンパイルが通りません。試してみましょう： 


$ cargo buiLd 

Compiling guessing_game v 0.1.0 ( file :/// proiects / guessing _ game ) 
error [ E 0308] : mismatched types ( 型が合いません） 

--> src / main . rs :23 : 21 


I 

23 | 

I 


match guess . cmp (& secret _ number ) { 

aaaaaaaaaaaaaa expected struct ' std :: string : : String ', 


found integral variable 

ど、整数型変数が見つかりました） 


(構造体 ' std : : string : : String ' を予期したけ 


= note : expected tvpe & std : : string: : String 
= note : found tvpe &-{. integerj - 


error : aborting due to previous error ( 先のエラーのため、処理を 中断し ます） 
Could not compile ' guessi ng _ game ' . (' guessi . ng _ game ' をコンノペイ ノレできませんで 

した） 


この エラーの 核は、 型の 不一致があると言っています。 Rust には、強い静的型システムがありま 
す。しかし、型推論にも対応しています 。 let guess = String : : new () と書いた時、コンパイラは、 
guess が String 型であるはずと推論してくれ、その型を明示させられることはありませんでした。一 
方で、 secremumber •変数は、数値型です。1から100を表すことができる数値型はいくつかありま 
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す： 1 _ 32 は32ビットの数字； U32 は32ビットの非負数字；彳 64 は64ビットの数字などです。 Rust で 
の標準は、 i32 型であり、型情報をどこかに追加して、コンパイラに異なる数値型だと推論させない 
限り、 secret_number の型はこれになります。エラーの原因は、 Rust では、文字列と数値型を比較で 
きないことです。 

究極的には、プログラムが入力として読み込む String 型を現実の数値型に変換し、予想と数値と 
して比較できるようにしたいわけです。これは、以下の 2 行を main 関数の本体に追記することでで 
きます： 

フアイル名： src / main.rs 

// --snip 


let mut guess = Stri ng: : new(); 

io :: stdin().read_line(&mut guess) 

.expect ("Failed to read line"); 

let guess : u32 = guess.trim().parse() 

.expect ("Please type a number!’ 1 ); // 数値を入力して くださ 


println! ("You guessed : {}" , guess); 

match guess.cmp(&secret_number) { 

Orderi ng: : Less => pri ntln! ("Too small! 11 ), 
Ordering: : Greater => println! ("Too big! ") , 
Orderi ng: : Equal=> println! ("You win!"), 



その 2 行とは： 

let guess : 1132 = guess.trim() .parse() 

.expect ("Please type a number!"); 

guess という名前の変数を生成しています。あれ、でも待って 0 もうプログラムには guess という 
名前の変数がありませんでしたっけ？確かにありますが、 Rust では、新しい値で guess の値を覆い 
隠す （ shadow ) ことが許されているのです。この機能は、値を別の型に変換したいシチュエーショ 
ンでよく使われます。シャドーイング （ shadowing ) のおかげで別々の変数を2つ作らされることな 
く、 guess という変数名を再利用することができるのです 0 guess_str と guess みたいなね（シャドー 
イングについては、第3章でもっと掘り下げます)。 

guess を guess.trim() .parse() という式に束縛しています。この式中の guess は、入力が入った 
String 型の元々の guess を指しています。 Stri ng オブジェクトの trim メソッドは、両端の空白をす 
ベて除去します。 u32 型は、数字しか含むことができませんが、ユーザは、 reacLline の処理を終え 
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るためにエンターを押さなければなりません。ユーザがエンターを押したら、改行文字が文字列に追 
加されます。具体例として、ユーザが5を入力して、エンターを押せば、 guess は次のようになりま 
す： 5\n 。 このいが「改行」、つまりエンターキーを押した結果を表しているわけです。 tHm メソッド 
は、 \n を削除するので、ただの 5 になります。 

文字列の parse メソッドは、文字列を解析して何らかの数値にします。このメソッドは、いろんな 
数値型を解析できるので、 let guess: u32 としてコンパイラに私たちが求めている型をズバリ示唆 
する必要があるのです。 guess の後のコロン（： ） がコンパイラに変数の型を注釈する合図になります。 
Rust には、組み込みの数値型がいくつかあります；ここの U32 型は、32ビットの非負整数です。 U32 
型は小さな非負整数のデフォルトの選択肢として丁度良いです。他の数値型については、第3章で学 
ぶでしょう。付け加えると、このサンプルプログラムの u32 という注釈と secret_n U mber 変数との比 
較は、 secret_number 変数も u3 2 型であるとコンパイラが推論することを意味します。従って、今で 
は比較が同じ型の2つの値で行われることになるわけです！ 

parse メソッドの呼び出しは、エラーになりやすいです。例としては、文字列がを含んでいた 
ら、数値に変換できるわけがありません。失敗する可能性があるので、 parse メソッドは、 Result 型を 
返すわけです。ちょうど、 （「 Result 型で失敗する可能性に対処する」節で先ほど議論した) reacLline 
メソッドのようにというわけですね。今回も、 expect メソッドを使用して Result 型を同じように扱 
います 0 この Result を expect メソッドを再度使用して、同じように扱います 0 もし、文字列から数 
値を生成できなかったために、 parse メソッドが Result 型の Err 列挙子を返したら、 expect メソッ 
ドの呼び出しは、ゲームをクラッシュさせ、与えたメッセージを表示します。もし、 parse メソッド 
が文字列の数値への変換に成功したら、 Result 型の Ok 列挙子を返し、 expect メソッドは、 Ok 値か 
ら必要な数値を返してくれます。 

さあ、プログラムを走らせましょう！ 

$ cargo run 

Compiling guessing_game v0.1.0 (file:///projects/guessing_game) 

Finished dev [unoptimized + debuginfo] target(s) in 0.43 secs 
Running 'target/debug/guessing_game' 

Guess the number! 

The secret number is: 58 
Please input your guess. 

76 

You guessed : 76 
Too big! 


いいですね！予想の前にスペースを追加したにもかかわらず、プログラムはちゃんとユーザが76 
と予想したことを導き出しました。プログラムを何回か走らせて、異なる入力の色々な振る舞いを確 
認してください：つまり、数字を正しく言い当てたり、大きすぎる値を予想したり、小さすぎる数字 
を入力したりということです。 

ここまでで大方ゲームはうまく動くようになりましたが、まだユーザは1回しか予想できません。 
ループを追加して、その部分を変更しましょう！ 
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2.5 ループで複数回の予想を可能にする 

loop キーワードは、無限ループを作り出します。これを追加して、ユーザが何回も予想できるよう 
にしましょう： 

フアイル名： src / main.rs 

// -- snip -- 

pnntln! ("The secret number is : {}" , secret _ number ); 
loop { 

println ! ("Please input your guess . 11 ); 

// -- snip -- 

match guess . cmp (& secret _ number ) { 

Ordering : : Less => pri ntln ! ("Too small ! 11 ), 

Ordering: : Greater => println! ("Too big ! ") , 

Ordering : : Equal => println! ("You win !"), 



見てわかる通り、予想入力部分以降をループに入れ込みました。ループ内の行にインデントを追加 
するのを忘れないようにして、またプログラムを走らせてみましょう。新たな問題が発生したことに 
気付いてください。プログラムが教えた通りに動作しているからですね：永遠に予想入力を求めるわ 
けです！これでは、ユーザが終了できないようです！ 

ユーザは、 ctrl - c というキーボードショートカットを使って、 いつでも プログラムを強制終了させ 
られます。しかし、「予想と秘密の数字を比較する」節の parse メソッドに関する議論で触れたよう 
に、この貪欲なモンスターを回避する別の方法があります：ユーザが数字以外の答えを入力すれば、 
プログラムはクラッシュするのです。ユーザは、その利点を活かして、終了することができます。以 
下のようにですね： 

$ cargo run 

Compiling guessing_game vO .1.0 げ i (_ e :/// pro ] ects / guessing _ game ) 

Finished dev [unoptimized + debuginfo ] target ( s ) in 1.50 secs 
Running ' target / debug / guessing _ game ' 

Guess the number ! 

The secret number is : 59 

Please input your guess . 

45 

You guessed : 45 

Too small ! 

Please input your guess . 

60 
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You guessed : 60 
Too big ! 

Please input vour guess . 

59 

You guessed : 59 
You win ! 

Please input your guess . 
quit 

thread ' main ' panicked at 'Please type a number ! : ParselntError { kind : 

InvalidDigit }', src / libcore / result . rs :785 
(スレッド 1 main | は ， 数字を入力してください！： ParselntError { kind : InvalidDigit 
} ' , src/li bco re / result . rs :785 でパニックしました） 
note : Run with ' RUST _ BACKTRACE =1' for a backtrace . 

(注釈： ' RUST _ BACKTRACE =1' で走らせるとパック ト レースを見れます） 

error : Process didn't exit successrully : target / deoug/guess (.exit code : 101) 

(エラー： プロセスは予期なく終了しました） 

quit と入力すれば、実際にゲームを終了できるわけですが、別に他の数字以外の入力でもそうなり 
ます。しかしながら、これは最低限度と言えるでしょう。正しい数字が予想されたら、自動的にゲー 
ムが停止してほしいわけです。 

2.5.1 正しい予想をした後に終了する 

b re a k 文を追加して、ユーザが勝った時にゲームが終了するようにプログラムしましょう： 

フアイル名： src / main.rs 

// __ snip -- 

match guess . cmp (& secret _ number ) i . 

Ordering : : Less => pri nt Ln ! ("Too small ! 11 ), 

Ordering: : Greater => println! ("Too big ! ") , 

Ordering : : Equal => { 

println! ("You win !"); 
break ; 

} 



break 文の 1 行を You win ! の後に追記することで、ユーザが秘密の数字を正確に予想した時に、プ 
ログラムはループを抜けるようになりました。 ついでに、 ループを抜けることは、プログラムを終了 
することを意味します。ループが main 関数の最後の部分だからですね。 
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2.5.2 不正な入力を処理する 

さらにゲームの振る舞いを改善するために、ユーザが数値以外を入力した時にプログラムをクラッ 
シュさせるのではなく、非数値を無視してユーザが数当てを続けられるようにしましょう！これは、 
guess が String 型から u 32 型に変換される行を改変することで達成できます。リスト 2-5 のように 
ですね。 

フ アイ ル名： src / main.rs 
// -- snip -- 

io : : stdin (). read _ line(&mut guess ) 

• expect ("Failed to read Line "); 

let guess : u 32 = match guess . trim (). parse () { 

Ok ( num ) => num , 

Err (_) => continue , 

}； 

println! ("You guessed : {}" , guess ); 

// __ snip -- 

リスト 2-5: 非数値の予想を無視し、プログラムをクラッシュさせるのではなく、もう1回予想し 
てもらう 


expect メソッドの呼び出しから match 式に切り替えることは、エラーでクラッシュする動作から 
エラー処理を行う処理に変更する一般的な手段になります。 parse メソッドは、 Result 型を返し、 
Result は Ok か Err の列挙子を取りうる列挙型であることを思い出してください。ここでは match 式 
を使っています。 cmp メソッドの Ordering という結果のような感じですね。 

parse メソッドは、文字列から数値への変換に成功したら、結果の数値を保持する Ok 値を返しま 
す。この Ok 値は、最初のアームのパターンにマッチし、この match 式は parse メソッドが生成し、 Ok 
値に格納した num の値を返すだけです。その数値が最終的に、生成している新しい guess 変数として 
欲しい場所に存在します。 

parse メソッドは、文字列から数値への変換に失敗したら、エラーに関する情報を多く含む Err 値 
を返します。この Err 値は、最初の match アームの Ok ( num ) というパターンにはマッチしないもの 
の、2畨目のアームの Err し）というパターンにはマッチするわけです。この_は、包括値です；この 
例では、保持している情報がどんなものでもいいから全ての Err 値にマッチさせたいと宣言していま 
す 0 従って、プログラムは2杳目のアームのコードを実行し （continue ですね)、これは、 loop の次 
のステップに移り、再度予想入力を求めるようプログラムに指示します。故に実質的には、プログラ 
ムは parse メソッドが遭遇しうる全てのエラーを無視するようになります！ 
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さて、プログラムの全てがうまく予想通りに動くはずです。試しましょう： 


$ cargo run 

Compiling guessing_game v 0.1.0 ( file :/// proiects / guessing _ game ) 
Running ' target / debug / guessing _ game ' 

Guess the number ! 


The secret number is : 61 
Please input your guess . 
10 


You guessed : 10 
Too small ! 

Please input your guess . 
99 


You guessed : 99 
Too big ! 

Please input your guess . 
foo 

Please input your guess . 
61 


You guessed : 61 
You win ! 


素晴らしい！最後にひとつまみ変更を加えて、数当てゲームを完了にしましょう。プログラムが未 
だに秘密の数字を出力していることを思い出してください。テスト中はうまく動くけど、ゲームを台 
無しにしてしまいます。秘密の数字を出力する println ! を削除しましょう。リスト 2-6 が成果物の 
コードです： 


ファイル名： src / main.rs 

extern crate rand ; 

use std : no ; 

use std : : cmp :: Ordering ; 

use rand :: Rng ; 

fn main () { 

printin! ("Guess the number !"); 

let secret_number = rand : : thread _ rng (). gen _ range ( l , 101) ; 


loop { 

println! ("Please input your guess ."); 

let mut guess = Stri ng : : new (); 

io :: stdin (). read _ line(&mut guess ) 

. expect ("Failed to read line "); 

let guess : u 32 = match guess . trim (). parse () { 
Ok ( num ) => num , 

Err (_) => continue , 
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}； 


pn ntln ! ("You guessed : {}" , guess ) : 


match guess . cmp (& secret _ number ) { 

Ordering: :Less => println! ("Too small !”）， 
Ordering: : Greater => println! ("Too big ! ") . 
Ordering : : Equal => { 

println! ("You win !"); 
break ; 

} 

} 


リスト 2-6: 数当てゲームの完全なコード 


2.6 まとめ 

ここまでで、数当てゲームの構築に成功しました。おめでとうございます！ 

このプロジエクトは、たくさんの新しい Rust の概念に触れる実践的な方法でした： let 、 match 、 
メソッド、関連関数、外部クレートの使用などなど。以降の数章で、これらの概念についてより深く 
学ぶことになるでしょう。第3章では、ほとんどのプログラミング言語に存在する、変数、データ型、 
関数などの概念について講義し、それらの Rust での使用方法について示します。第4章では、所有 
権について見ます。これにより、 Rust は他の言語とかけ離れた存在になっています。第5章では、構 
造体とメソッド記法について議論し、第6章では enum の動作法を説明します。 



一般的なプログラミングの概念 


この章では、ほとんど全てのプログラミング言語で見られる概念を講義し、それらが Rust におい 
て、どう動作するかを見ていきます。多くのプログラミング言語は、その核心において、いろいろな 
ものを共有しています。この章で提示する概念は、全て Rust に固有のものではありませんが 、 Rust 
の文脈で議論し、これらの概念を使用することにまつわる仕様を説明します。 

具体的には、変数、基本的な型、関数、コメント、そしてフロー制御について学びます。これらの 
基礎は全ての Rust プログラムに存在するものであり、それらを早期に学ぶことにより、強力な基礎 
を築くことになるでしよう。 

3.0.1 キーワード 

Rust 言語にも他の言語同様、キーワードが存在し、これらは言語だけが使用できるようになっ 
ています。これらの単語は、変数や関数名には使えないことを弁えておいてください。ほとん 
どのキーワードは、特別な意味を持っており、自らの Rust プログラムにおいて、様々な作業 
をこなすために使用することができます；いくつかは、紐付けられた機能がないものの、将来 
Rust に追加されるかもしれない機能用に予約されています。キーワードの一覧は、付録 A で 
確認できます。 

3.1 変数と可変性 

第2章で触れた通り、変数は標準で不変になります。これは、 Rust が提供する安全性や簡便な並行 
性の利点を享受する形でコードを書くための選択の1つです。ところが、まだ変数を可変にするとい 
う選択肢も残されています。どのように、そしてなぜ Rust は不変性を推奨するのか、さらには、な 
ぜそれとは違う道を選びたくなることがあるのか見ていきましよう。 

変数が不変であると、値が一旦名前に束縛されたら、その値を変えることができません。これを具 
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体的に説明するために、 projects ディレクトリに cargo new --bin variables コマンドを使って、 
variables という名前のプロジヱクトを生成しましょう。 

それから、新規作成した variables ディレクトリで、 src/main.rs ファイルを開き、その中身を 
以下のコードに置き換えましょう。このコードはまだコンパイルできません： 

フアイル名： src / main.rs 

fn mann () { 
let x = 5; 

pri ntln ! ("The value of x is : {}" , x ); // x の値は {} です 

x = 6; 

println! ("The value of x is : {}" , x ); 

} 


これを保存し、 cargo run コマンドでプログラムを走らせてください。次の出力に示されているよ 
うな エラーメッセージを 受け取るはずです： 


error[E0384] : cannot assgin twice immutable van able 'x 
( 不変変数 ' x' に 2 回代入できません） 

-- > src/main.rs :4:5 


2 


3 

4 


let x = 5; 

- first assignment to x 
('x' への最初の代入） 
println!("The value of x is: {}", x); 
x = 6; 

aaaaa cannot assign twice to immutable variable 


この例では、コンパイラがプログラムに潜むエラーを見つけ出す手助けをしてくれることが示され 
ています。コンパイルエラーは、イライラすることもあるものですが、まだプログラムにしてほしい 
ことを安全に行えていないだけということなのです；エラーが出るからといって、あなたがいいプロ 
グラマではないという意味ではありません！経験豊富な Rustacean でも、コンパイルエラーを出す 
ことはあります。 

このエラーは、エラーの原因が 不変変数 x に 2 回 代入で きないであると示しています。不変な x という変 
数に第2段階の値を代入しようとしたからです。 

以前に不変と指定された値を変えようとした時に、 コンパイルエラーが 出るのは重要なことです。 
なぜなら、この状況はまさしく、バグに繫がるからです。コードのある部分は、値が変わることはな 
いという前提のもとに処理を行い、別の部分がその値を変更していたら、最初の部分が目論見通りに 
動いていない可能性があるのです。このようなバグの発生は、事実 （訳注： 実際にプログラムを走らせ 
た結果のことと思われる）の後には追いかけづらいものです。特に第2のコード片が、値を時々しか 
変えない場合、尚更です。 

Rust では、値が不変であると宣言したら、本当に変わらないことをコンパイラが担保してくれま 
す。つまり、コードを読み書きする際に、どこでどうやって値が変化しているかを追いかける必要が 
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なくなります。故にコードを通して正しいことを確認するのが簡単になるのです。 

しかし、可変性は時として非常に有益なこともあります。変数は、標準でのみ、不変です。つまり、 
第2章のように変数名の前に mut キーワードを付けることで、可変にできるわけです。この値が変化 
できるようにするとともに、 mut により、未来の読者に対してコードの別の部分がこの変数の値を変 
える可能性を示すことで、その意図を汲ませることができるのです。 

例として、 src / main . rs フアイルを以下のように書き換えてください： 

フアイル名： src / main.rs 

fn main () { 

let mut x = 5; 

println! ("The value of x is : {}" , x ); 
x = 6; 

println! ("The value of x is : {}" , x ); 

} 

今、このプログラムを走らせると、以下のような出力が得られます： 

$ cargo run 

Compiling variables v 0.1.0 ( file :/ // proiects / vanables ) 

Finished dev [unoptimized + debuginfo ] target ( s ) in 0.30 secs 
Running ' target / debug / variables ' 

The value of x is : 5 (x の値は 5 です） 

The value of x is : 6 

mut キーワードが使われると、 x が束縛している値を 5 から 6 に変更できます。変数を可変にする 
方が、不変変数だけがあるよりも書きやすくなるので、変数を可変にしたくなることもあるでしょう。 

考えるべきトレードオフはバグの予防以外にも、いくつかあります。例えば、大きなデータ構造を 
使う場合などです。インスタンスを可変にして変更できるようにする方が、いちいちインスタンスを 
コピーして新しく メモリ割り当てされたインスタンスを返すよりも速くなります。小規模なデータ構 
造なら、新規インスタンスを生成して、もっと関数型っぽいコードを書く方が通して考えやすくなる 
ため、低パフォーマンスは、その簡潔性を得るのに足りうるペナルティになるかもしれません。 

3.1.1 変数と定数 （ constants ) の違い 

変数の値を変更できないようにするといえば、他の多くの言語も持っている別のプログラミング概 
念を思い浮かべるかもしれません：定数です。不変変数のように、定数は名前に束縛され、変更する 
ことが叶わない値のことですが、定数と変数の間にはいくつかの違いがあります。 

まず、定数には mut キーワードは使えません：定数は標準で不変であるだけでなく、常に不変なの 
です。 

定数は let キーワードの代わりに、 const キーワードで宣言し、値の型は必ず注釈しなければなり 
ません。型と型注釈に ついては 次のセクション、「データ型」で講義しますので、その詳細に ついて 気 
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にする必要はありません。ただ単に型は常に注釈しなければならないのだと思っていてください。 

定数はどんな スコープ でも定義できます。 グローバルスコープ も含めてです。なので、いろんなと 
ころで使用される可能性のある値を定義するのに役に立ちます。 

最後の違いは、定数は定数式にしかセットできないことです。関数呼び出し結果や、実行時に評価 
される値にはセツトできません。 

定数の名前が MAX_POINTS で、値が100,000にセットされた定数定義の例をご覧ください。 （Rust 
の定数の命名規則は、全て大文字でアンダースコアで単語区切りすることです)： 

const MAX_POINTS: u32 =100_000; 

定数は、プログラムが走る期間、定義されたスコープ内でずっと有効です。従って、プログラムの 
いろんなところで使用される可能性のあるアプリケーション空間の値を定義するのに有益な選択肢に 
なります。例えば、ゲームでプレイヤーが取得可能なポイントの最高値や、光速度などですね。 

プログラム中で使用されるハードコードされた値に対して、定数として名前付けすることは、コー 
ドの将来的な管理者にとって値の意味を汲むのに役に立ちます。将来、ハードコードされた値を変え 
る必要が出た時に、たった1箇所を変更するだけで済むようにもしてくれます。 

3.1.2 シャドーイング 

第2章の数当てゲームのチュートリアル、「予想と秘密の数字を比較する」節で見たように、前に定 
義した変数と同じ名前の変数を新しく宣言でき、新しい変数は、前の変数を覆い隠します。 Rustacean 
はこれを最初の変数は、2香目の変数に覆い隠されたと言い、この変数を使用した際に、2番目の変 
数の値が現れるということです。以下のようにして、同じ変数名を用いて変数を覆い隠し、 let キー 
ワードの使用を繰り返します： 

フ アイ ル名： src / main.rs 

fn mann() { 
let x = 5; 

let x = x + 1; 

let x = x ^ 2; 

println! ("The value of x is: {}" , x); 

} 

このプログラムはまず、 X を 5 という値に束縛します。それから let x =を繰り返すことで x を覆 
い隠し、元の値に1を加えることになるので、 x の値は6になります。3番目の let 文も x を覆い隠 
し、以前の値に2をかけることになるので、 x の最終的な値は12になります。このプログラムを走ら 
せたら、以下のように出力するでしょう： 
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$ cargo run 

CompiLing variables v0.1.0 (rile:/ //proiects/vanables) 

Finished dev [unoptimized + debuginfo] target(s) in 0.31 secs 
Running 'target/debug/variables' 

The value of x is:12 

シャドーイングは、変数を mut にするのとは違います。なぜなら、 let キーワードを使わずに、誤っ 
てこの変数に再代入を試みようものなら、コンパイルエラーが出るからです。 let を使うことで、値 
にちょっとした加工は行えますが、その加工が終わったら、変数は不変になるわけです。 

mut と上書きのもう一つの違いは、再度 let キーワードを使用したら、実効的には新しい変数を生 
成していることになるので、値の型を変えつつ、同じ変数名を使いまわせることです。例えば、プロ 
グラムが ユーザに 何らかのテキストに対して空白文字を入力することで何個分のスペースを表示した 
いかを尋ねますが、ただ、実際にはこの入力を数値として保持したいとしましょう： 

Let spaces = " " ; 

let spaces = spaces . len (); 

この文法要素は、容認されます。というのも、最初の spaces 変数は文字列型であり、2番目の 
spaces 変数は、たまたま最初の変数と同じ名前になったまっさらな変数のわけですが、数値型にな 
るからです。故に、シャドーイングのおかげで、異なる名前を思いつく必要がなくなるわけです。 
spaces_str と spaces_num などですね；代わりに、よりシンプルな spaces という名前を再利用できる 
わけです。一方で、この場合に mut を使おうとすると、以下に示した通りですが、コンパイル エラー 
になるわけです： 


let mut spaces = " " 

spaces = spaces.len(); 


変数の型を可変にすることは許されていないと言われているわけです： 

error [E0308] : mismatched types ( 型が合いません） 

-- > src/mann.rs:3:14 

I 

3 | spaces = soaces.len(); 

| a 八八八八八八八八八八八 expected &str, found usize 

| (&str 型を予期しましたが、 usize が見つかりました） 

I 

= note : expected type &str 
found type usize 

さあ、変数が動作する方法を見てきたので、今度は変数が取りうるデータ型について見ていきま 
しよう。 
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3.2 データ型 

Rust における値は全て、何らかの データ型 になり、 コンパイ ラがどんなデータが指定されているか 
知れるので、そのデータの取り扱い方も把握できるというわけです。2種のデータ型のサブセットを 
見ましょう：スカラー型と複合型です。 

Rust は 静的型付き 言語であることを弁えておいてください。つまり、コンパイル時に全ての変数の 
型が判明している必要があるということです。コンパイラは通常、値と使用方法に基づいて、使用し 
たい型を推論してくれます。複数の型が推論される可能性がある場合、例えば、第2章の「予想と秘 
密の数字を比較する」節で parse メソッドを使って String 型を数値型に変換した時のように、複数 
の型が可能な場合には、型注釈をつけなければいけません。以下のようにですね： 

let guess : u 32 = "42" . parse () . expect ("Not a number ! ") ; // 数字ではありませ 

ん！ 

ここで型注釈を付けなければ、コンパイラは以下のエラーを表示し、これは可能性のある型のうち、 
どの型を使用したいのかを知るのに、コンパイラがプログラマからもっと情報を得る必要があること 
を意味します： 

error [ E 0282] : type annotations needed 
(型注釈が必要です） 

-- > src / main . rs :2:9 

I 

2 | let guess = M 42" . parse (). expect ("Not a number *!"); 

| aaaaa cannot infer * type for 

i r _' の型が推論できません） 

I 

= note : type annotations or generic parameter binding required 

(注釈：型注釈、またはジェネリクス引数束縛が必要です） 

他のデータ型についても、様々な型注釈を目にすることになるでしょう。 

3.2.1 スカラー型 

スカラー 型は、単独の値を表します。 Rust には主に4つの スカラー 型があります：整数、浮動小数 
点数、論理 fit、 最後に文字です。他のプログラミング言語でも、これらの型を見かけたことはあるで 
しょう。 Rust での動作方法に飛び込みましょう。 

3.2.1.1 整数型 

整数とは、小数部分のない数値のことです。第2章で一つの整数型を使用しましたね。 U 32 型です。 
この型定義は、紐付けられる値が、符号なし整数（符号付き整数は u ではなく、 i で始まります）にな 
り、これは、32ビット分のサイズを取ります。表 3-1 は、 Rust の組み込み整数型を表示しています。 
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符号付きと符号なし欄の各バリアント（例： il6) を使用して、整数値の型を宣言することができます。 
表 3-1: Rust の整数型 


大きさ 

符号付き 

符号なし 

8-bit 

i 8 

u 8 

16-bit 

il 6 

ul 6 

32-bit 

i 32 

u 32 

64-bit 

i 64 

u 64 

arch 

isize 

usi ze 


各バリアントは、符号付きか符号なしかを選べ、明示的なサイズを持ちます。符号付きと符号なし 
は、数値が正負を持つかどうかを示します。つまり、数値が符号を持つ必要があるかどうか（符号付 
き)、または、絶対に正数にしかならず符号なしで表現できるかどうか（符号なし）です。これは、数 
値を紙に書き下すのと似ています：符号が問題になるなら、数値はプラス記号、またはマイナス記号 
とともに表示されます；しかしながら、その数値が正数であると仮定することが安全なら、符号なし 
で表示できるわけです。符号付き数値は、2の補数表現で保持されます（これが何なのか確信を持てな 
いのであれば、ネットで検索することができます。まあ要するに、この解説は、この本の範疇外とい 
うわけです)。 

各符号付きバリアントは、 -(2 n - 1 )以上 2 n - 1 - 1以下の数値を保持でき、ここで n はこのバリアン 
卜が使用するビット数です。以上から、 is 型は-(2 7 )から 2 7 -1 まで、つまり、 -128 から127までを 
保持できます。符号なしバリアントは、0以上 2 n -l 以下を保持できるので、 us 型は、0から2 8 -1 
までの値、つまり、0から255までを保持できることになります。 

加えて、 isize と usize 型は、プログラムが動作しているコンピュータの種類に依存します： 64 
ビットアーキテクチャなら、64ビットですし、32ビットアーキテクチャなら、32ビットになります。 

整数リテラル（訳注：リテラルとは、見たままの値ということ）は、表 3-2 に示すどの形式でも記述 
することができます。パイトリテラルを除く数値リテラルは全て、型接尾辞（例えば、 57U8) と_を見 
た目の区切り記号（例えば、 i _000 ) に付加することができます。 

表 3-2: Rust の整数リテラル 


数値リテラル 

例 

10 進数 

98.222 

16 進数 

0 xff 

8進数 

0077 

2進数 

0 bllll _0000 

バイト （ U 8 だけ） 

b ' A ' 
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では、どの整数型を使うべきかはどう把握すれば いいので しょうか？もし確信が持てないのなら 
ば、 Rust の基準型は一般的にいい選択肢になります。整数型の基準は i 32 型です： 64 ビットシステ 
ム上でも、この型が普通最速になります。 isize と usize を使う主な状況は、何らかの コレクション 
にアクセスすることです。 

3.2.1.2 浮動小数点型 

Rust にはさらに、浮動小数点数に対しても、 2 種類の基本型があり、浮動小数点数とは数値に小数 
点がついたもののことです。 Rust の浮動小数点型は、 f 32 と f 64 で、それぞれ 32 ビットと 64 ビッ 
トサイズです。基準型は f 64 です。なぜなら、現代の CPU では、 f 32 とほぼ同スピードにもかかわら 
ず、より精度が高くなるからです。 

実際に動作している浮動小数点数の例をご覧ください： 

フアイル名： src / main.rs 

fn mann () { 

let x = 2.0; // f 64 

let y ： f 32 =3.0； // f 32 

} 

浮動小数点数は、 IEEE -754 規格に従って表現されています。 f 32 が単精度浮動小数点数、 f 64 が倍 
精度浮動小数点数です。 

3.2.1.3 数値演算 

Rust にも全数値型に期待されうる標準的な数学演算が用意されています：足し算、引き算、掛け 
算、割り算、余りです。以下の例では、 let 文での各演算の使用方法をご覧になれます： 

フアイル名： src / main.rs 

fn mann () { 

//足し算 

let sum =5+10; 

// 引き算 

let difference = 95.5 - 4.3; 


// 掛け算 

let product = 4 ^ 30; 


// 割り算 

let quotient = 56.7 / 32.2; 


} 


//余り 

let remainder = 43 96 5; 
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これらの文の各式は、数学演算子を使用しており、一つの値に評価され、そして、変数に束縛され 
ます。付録 B に Rust で使える演算子の一覧が載っています。 

3.2.1.4 論理値型 

他の多くの言語同様、 Rust の論理値型も取りうる値は二つしかありません： true と false です。 
Rust の論理値型は、 bool と指定されます。例です： 

フアイル名： src / main.rs 

fn mann() { 

let t = true; 

let f: bool = false; // 明示的型注釈付きで 

} 

論理値を使う主な手段は、条件式です。例えば、 if 式などですね。 if 式の Rust での動作方法につ 
いては、「制御 フロー」 節で講義します。 

3.2.1.5 文字型 

ここまで、数値型のみ扱ってきましたが、 Rust には文字も用意されています。 Rust の char 型は、 
言語の最も基本的なアルファべット型であり、以下のコードでその使用方法の一例を見ることができ 
ます。 （char は、ダブルクォーテーションマークを使用する文字列に対して、シングルクォートで指 
定されることに注意してください。） 

フアイル名： src / main.rs 

fn main() { 
let c = 'z'; 
let z = 'Z'; 

let heart_eyed_cat = 1 想 ， ； // ハート目の猫 

} 

Rust の char 型は、ユニコードのスカラー値を表します。これはつまり、アスキーよりもずっとた 
くさんのものを表せるということです。アクセント 文字； 中国語、日本語、韓国語 文字；絵文字； ゼロ 
幅スペースは、全て Rust では、有効な char ■型になります。ユニコードスカラー値は、 U+0000 から 
U+D7FF までと U+E000 から U + 10FFFF までの範囲になります。ところが、「文字」は実はユニコードの 
概念ではないので、文字とは何かという人間としての直観は、 RllSt における char* 値が何かとは合致 
しない可能性があります。この話題については、第8章の「文字列」で詳しく議論しましょう。 
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3.2.2 複合型 

複合型により、複数の値を一つの型にまとめることができます。 Rust には、2種類の基本的な複合 
型があります：タプルと配列です。 

3.2.2. 1タプル型 

タプルは、複数の型の何らかの値を一つの複合型にまとめ上げる一般的な手段です。 

タプルは、丸かっこの中にカンマ区切りの値リストを書くことで生成します。タプルの位置ごとに 
型があり、タプル内の値はそれぞれ全てが同じ型である必要はありません。今回の例では、型注釈を 
あえて追加しました： 

フ アイ ル名： src / main.rs 

fn mann() { 

let tup : (i32 ， f64, u8) = (500, 6.4,1); 

} 

変数 tup は、タプル全体に束縛されています。なぜなら、タプルは、一つの複合要素と考えられる 
からです。タプルから個々の値を取り出すには、パターンマッチングを使用して分解することができ 
ます。以下のように： 

フ アイ ル名： src / main.rs 

fn mann() { 

let tup = (500 ， 6.4,1); 

let (x, y, z) = tup; 

println! ("The value of y is: {}" , y); 

} 

このプログラムは、まずタブルを生成し、それを変数 tup に束縛しています。それから let とパ 
ターンを使って tup 変数の中身を3つの個別の変数 （ x 、 y 、 z ですね）に変換しています。この過程 
は、分配と呼ばれます。単独のタプルを破壊して三分割しているからです。最後に、プログラムは;/ 
変数の値を出力し、 6.4 と表示されます。 

パターンマッチングを通しての分配の他にも、アクセスしたい値の番号をピリオド （•） に続けて書 
くことで、タプルの要素に直接アクセスすることもできます。例です： 

フ アイ ル名： src / main.rs 

fn mann() { 

let x: (i 32 , f64, u8) = (500, 6.4,1); 
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let five_hundred = x. 0; 
let six_point_four = x.1; 
let one = x.2; 

} 

このプログラムは、新しいタプル X を作成し、添え字アクセスで各要素に対して新しい変数も作成 
しています。多くのプログラミング言語同様、タプルの最初の添え字は〇です。 

3.2.2.2配列型 

配列によっても、複数の値のコレクションを得ることができます。タプルと異なり、配列の全要素 
は、同じ型でなければなりません。 Rust の配列は、他の言語と異なっています。 Rust の配列は、固 
定長なのです：一度宣言されたら、サイズを伸ばすことも縮めることもできません。 

Rust では、配列に入れる要素は、角かっこ内にカンマ区切りリストとして記述します： 

フ アイ ル名： src / main.rs 

fn mann() { 

let a =[1 ， 2 ， 3 ， 4 ， 5]; 

} 

配列は、ヒープよりもスタック（スタックとヒープについては第 4 章で詳（つまび）らかに議論しま 
す）にデータのメモリを確保したい時、または、常に固定長の要素があることを確認したい時に有効 
です。ただ、配列は、ベクタ型ほど柔軟ではありません。ベクタは、標準ライブラリによって提供さ 
れている配列と似たようなコレクション型で、こちらは、サイズを伸縮させることができます。配列 
とべクタ型、どちらを使うべきか確信が持てない時は、おそらくベクタ型を使うべきです。第8章で 
ベクタについて詳細に議論します。 

ベクタ型よりも配列を使いたくなるかもしれない例は、1年の月の名前を扱うプログラムです。そ 
のようなプログラムで、月を追加したり削除したりすることまずないので、配列を使用できます。常 
に12個要素があることもわかってますからね： 

let months = ["January" , "February" , "March" , "April" , "May" , "June" , "July" , 
"August" , "September" , "October" , "November" , "December"] ; 

■配列の要素にアクセスする配列は、スタック上に確保される一塊のメモリです。添え字によって、 
配列の要素にこのようにアクセスすることができます： 

フ アイ ル名： src / main.rs 


fn main() i 
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let a = [1, 2, 3, 4, 5]; 

let first = a[0]; 
let second = a[1]; 

} 

この例では、 first という名前の変数には 1 という値が格納されます。配列の [0] 番目にある値が、 
それだからですね。 second という名前の変数には、配列の [1] 番目の値 2 が格納されます。 

■配列要素への無効なアクセス配列の終端を越えて要素にアクセスしようとしたら、どうなるで 
しょうか？先ほどの例を以下のように変えたとすると、 コンパイルは 通りますが、実行すると エラー 
で終了します： 

フアイル名： src / main.rs 

fn mann() { 

let a =[1, 2, 3, 4, 5]; 
let index =10; 

let element = a [index]; 

pri ntln! ("The value of element is: {}" , element); // 要素の値は {} です 

} 

このコードを cargo run で走らせると、以下のような結果になります： 

$ cargo run 

Compiling arrays v0.1.0 (file:///projects/arravs) 

Finished dev [unoptimized + debuginfo] target(s) in 0.31 secs 
Running 'target/debug/arrays' 

thread '<main>' panicked at 'index out of bounds : the len is 5 but the index is 
10', src/main.rs:6 

スレッド 1 く main 〉 1 は 1 範囲外アクセス：長さは 5 ですが、添え字は 10 でした 1 ， src/main. rs 
:6 

でパニック しました 

note : Run with 'RUST_BACKTRACE=1' for a backtrace. 

コンパイルでは何もエラーが出なかったものの、プログラムは実行時エラーに陥り、正常終了しま 
せんでした。要素に添え字アクセスを試みると、言語は、指定されたその添え字が配列長よりも小さ 
いかを確認してくれます。添え字が配列長よりも大きければ、言語はパニックします。パニックとは、 
プログラムがエラーで終了したことを表す Rust 用語です。 

これは、実際に稼働している Rust の安全機構の最初の例になります。低レベル言語の多くでは、 
この種のチヱックは行われないため、間違った添え字を与えると、無効なメモリにアクセスできてし 
まいます。 Rust では、メモリアクセスを許可し、処理を継続する代わりに即座にプログラムを終了す 
ることで、この種のエラーからプログラマを保護しています。 Rust のエラー処理については、第9章 
でもっと議論します。 
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3.3 関数 

関数は、 Rust のコードにおいてよく見かける存在です。既に、言語において最も重要な関数のうち 
の一つを目撃していますね：そう、 main 関数です。これは、多くのプログラムのエントリーポイント 
(訳注： プログラム実行時に最初に走る関数のこと）になります。 fn キーワードもすでに見かけました 
ね。これによって新しい関数を宣言することができます。 

Rust の関数と変数の命名規則は、スネークケース （訳注： some _ variable のような命名規則）を使 
うのが慣例です。スネークケースとは、全文字を小文字にし、単語区切りにアンダースコアを使うこ 
とです。以下のプログラムで、サンプルの関数定義をご覧ください： 

ファイル名： src / main.rs 

fn mann() { 

println! ("Hello, world!"); 
another_function(); 

} 

fn another_function() { 

println! ("Another function.’ 1 ); // 別の関数 

} 

Rust において関数定義は、 fn キーワードで始まり、関数名の後に丸かっこの組が続きます。波かっ 
こが、コンパイラに関数本体の開始と終了の位置を伝えます。 

定義した関数は、名前に丸かっこの組を続けることで呼び出すことができます。 another_function 
関数がプログラム内で定義されているので、 main 関数内から呼び出すことができるわけです。 ソース 
コード中で another_function を main 関数の後に定義していることに注目してください；勿論、 main 
関数の前に定義することもできます。コンパイラは、関数がどこで定義されているかは気にしません。 
どこかで定義されていることのみ気にします。 

functions という名前の新しいバイナリ生成プロジヱクトを始めて、関数についてさらに深く探 
究していきましよう 〇 another_function の例を src / main . rs ファイルに配置して、走らせてくださ 
い。以下のような出力が得られるはずです： 

$ cargo run 

Compiling functions v0.1.0 (file:///proiects/runctions) 

Finished dev [unoptimized + debuginfo] target(s) in 0.28 secs 
Running 'target/debug/functions' 

Hello, world! 

Another function. 


行出力は、 main 関数内に書かれた順序で実行されています。最初に” Hello , world ” メッセージが 
出て、それから another _ function が呼ばれて、こちらのメッセ^ージが出力されています。 
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3.3.1 関数の引数 

関数は、引数を持つようにも定義できます。弓 I 数とは、関数シグニチャの一部になる特別な変数の 
ことです。関数に引数があると、引数の位置に実際の値を与えることができます。技術的にはこの実 
際の値は実引数と呼ばれますが、普段の会話では、仮引数（” parameter ”） と実引数（” argument ”) 
を関数定義の変数と関数呼び出し時に渡す実際の値、両方の意味に区別なく使います （訳注： 日本語で 
は、特別区別する意図がない限り、どちらも単に引数と呼ぶことが多いでしょう）。 

以下の書き直した a not he r_f unction では、 Rust の仮弓 I 数がどのようなものかを示しています： 

フアイル名： src / main.rs 

fn mann() { 

another_function(5); 

} 

fn another_function(x: -i32) { 

pri ntln! ("The value of x is: {}" , x); // x の値は {} です 

} 

このプログラムを走らせてみてください；以下のような出力が得られるはずです： 

$ cargo run 

Compiling functions v0.1.0 (file:///proiects/runctions) 

Finished dev [unoptimized + debuginfo] target(s) in 1.21 secs 
Running 'target/debug/functions' 

The value of x is: 5 

another_function の宣言には、 x という名前の仮引数があります。 x の型は、 132 と指定され てい 
ます。値 5 が another_function に渡されると、 pri ntln ! マクロに より、フォー マツト 文字列中の 1 
組の波かっこがあった位置に値 5 が出力されます。 

関数シグニチャにおいて、各仮引数の型を宣言しなければなりません。これは、 Rust の設計におい 
て、意図的な判断です：関数定義で型注釈が必要不可欠ということは、コンパイラがその意図すると 
ころを推し量るのに、プログラマがコードの他の箇所で使用する必要がないということを意味します。 

関数に複数の仮引数を持たせたいときは、仮引数定義をカンマで区切ってください。こんな感じ 
です： 

フアイル名： src / main.rs 

fn mann() { 

another_function(5, 6); 

} 


fn another_function(x: i32 , y : i32) { 

println! ("The value of x is: {}" , x); 
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println ! ("The value of y is : {}" , y ); 

} 

この例では、 2 引数の関数を生成しています。そして、引数はどちらも i 32 型です。それからこの 
関数は、仮引数の値を両方出力します。関数引数は、全てが同じ型である必要はありません。今回は、 
偶然同じになつただけです。 

このコードを走らせてみましょう。今、 function プロジェクトの src / main.rs ファイルに記載 
されているプログラムを先ほどの例と置き換えて 、 cargo run で走らせてください： 

$ cargo run 

Compiling functions v 0.1.0 ( file :/// proiects / runctions ) 

Finished dev [unoptimized + debuginfo ] target ( s ) in 0.31 secs 
Running ' target / debug / functions ' 

The value of x is : 5 
The value of y is : 6 

x に対して値5、 y に対して値 6 を渡して関数を呼び出したので、この二つの文字列は、この値で 
出力されました。 


3.3.2 関数本体は、文と式を含む 

関数本体は、文が並び、最後に式を置くか文を置くという形で形成されます。現在までには、式 
で終わらない関数だけを見てきたわけですが、式が文の一部になっているものなら見かけましたね。 
Rust は、式指向言語なので、これは理解しておくべき重要な差異になります。他の言語にこの差異は 
ありませんので、文と式がなんなのかと、その違いが関数本体にどんな影響を与えるかを見ていきま 
しょう0 

実のところ、もう文と式は使っています。文とは、なんらかの動作をして値を返さない命令です。 
式は結果値に評価されます。ちょっと例を眺めてみましょう。 

let キーワードを使用して変数を生成し、値を代入することは文になります。リスト 3-1 で 
let y = 6;は文です。 

フアイル名： src / main.rs 

fn mann () { 
let y = 6; 

} 

リスト 3-1：1 文を含む main 関数宣言 

関数定義も文になります。つまり、先の例は全体としても文になるわけです。 

文は値を返しません。故に、 let 文を他の変数に代入することはできません。以下のコードではそ 
れを試みていますが、エラーになります： 
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フアイル名： src / mam.rs 

fn mann () { 

let x = (let y = 6); 

} 

このプログラムを実行すると、以下のようなエラーが出るでしょう： 

$ cargo run 

Compiling functions v 0.1.0 ( file :/// proiects / runctions ) 
error : expected expression , found statement (' let ') 

(エラー： 式を予期しましたが、文が見つかりました (' let ')) 

-- > src / main . rs :2:14 

I 

2 | let x =(let y = 6); 

| AAA 

I 

= note : variable declaration using ' let ' is a statement 
( 注釈： ' let ' を使う変数宣言は、文です） 

この let y = 6 という文は値を返さないので、 x に束縛するものがないわけです。これは、 C や 
Ruby などの言語とは異なる動作です。 C や Ruby では、代入は代入値を返します。これらの言語で 
は、 x = y = 6 と書いて、 x も y も値6になるようにできるのですが、 Rust においては、そうは問屋 
が卸さないわけです。 

式は何かに評価され、これからあなたが書く Rust コードの多くを構成します。簡単な数学演算 
(5 + 6 など）を思い浮かべましょう。この例は、値 11 に評価される式です。式は文の一部になりえま 
す：リスト 3-1 において、 let y = 6 という文の 6 は値 6 に評価される式です。関数呼び出しも式で 
す。マクロ呼び出しも式です。新しいスコープを作る際に使用するブロック （{}) も式です： 

フアイル名： src / main.rs 

fn mann () { 
let x = 5; 

let y = { 

let x = 3; 
x + 1 

}； 


println! ("The value of y is : {}" , y ); 

} 

以下の式： 


{ 


let x = 3; 
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} 

は今回の場合、 4 に評価されるブロックです。その値が、 let 文の一部として y に束縛されます。今 
まで見かけてきた行と異なり、文末にセミコロンがついていない x +1の行に気をつけてください。 
式は終端にセミコロンを含みません。式の終端にセミコロンを付けたら、文に変えてしまいます。そ 
して、文は値を返しません。次に関数の戻り値や式を見ていく際にこのことを肝に銘じておいてくだ 
さい。 

3.3.3 戻り値のある関数 

関数は、それを呼び出したコードに値を返すことができます。戻り値に名前を付けはしませんが、 
矢印 （- >) の後に型を書いて確かに宣言します。 Rust では、関数の戻り値は、関数本体ブロックの最 
後の式の値と同義です。 return キーワードで関数から早期リターンし、値を指定することもできます 
が、多くの関数は最後の式を暗黙的に返します。こちらが、値を返す関数の例です： 

フアイル名： src / main.rs 

fn five() -> i 32 { 

5 

} 

fn mann() { 

let x = ti ve(); 

println! ("The value of x is : {}" , x); 

} 

five 関数内には、関数呼び出しもマクロ呼び出しも、 let 文でさえ存在しません。数字の5が単独 
であるだけです。これは、 Rust において、完璧に問題ない関数です。関数の戻り値型が-> i32 と指 
定されていることにも注目してください。このコードを実行してみましょう；出力はこんな感じにな 
るはずです： 

$ cargo run 

Compiling functions v0.1.0 (file:///proiects/runctions) 

Finished dev [unoptimized + debuginfo] target(s) in 0.30 secs 
Running 'target/debug/functions' 

The value of x is: 5 

five 内の 5 が関数の戻り値です。だから、戻り値型が i32 なのです。これについてもっと深く考察 
しましょう。重要な箇所は 2 つあります：まず、 let x = five() という行は、関数の戻り値を使って 
変数を初期化していることを示しています。関数 five は 5 を返すので、この行は以下のように書く 
のと同義です： 


let x = 5; 
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2番目に、 f 彳 ve 関数は仮引数をもたず、戻り値型を定義していますが、関数本体はセミコロンなし 
の 5 単独です。なぜなら、これが返したい値になる式だからです。 

もう一つ別の例を見ましょう： 

フアイル名： src / main.rs 

fn mann () { 

let x = plus _ one (5); 

println! ("The value of x is : {}" , x ); 

} 

fn plus 一 one ( x : i 32) -> i32 { 
x + 1 

} 

このコ^ ー ドを走らせると、 The value of x is : 6 と出力されるでしょう。しかし、 x + 1 を含む行 
の終端にセミコロンを付けて、式から文に変えたら、エラーになるでしょう： 

フアイル名： src / main.rs 

fn mann () { 

let x = plus _ one (5); 

println! ("The value of x is : {}" , x ); 

} 

fn plus 一 one ( x : i 32) -> i32 { 
x + 1; 

} 


このコードを実行すると、以下のようにエラーが出ます: 


error[E0308] : mismatched types 
( 型が合いません） 
-- > src/main.rs :7:28 


fn plus_one(x : i32) -> i32 { 


8 


9 


x + 1; 

- help : consider removing this semicolon 

} 

a expected i32, found () 

(i32 を予期したのに、 （） 型が見つかりました） 


note : expected type i32 
round type () 
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メインのエラーメッセージである「型が合いません」でこのコードの根本的な問題が明らかになる 
でしょう。関数 plus_one の定義では、 i 32 型を返すと言っているのに、文は値に評価されないからで 
す。このことは、（）、つまり空のタプルとして表現されています。それゆえに、何も戻り値がなく、 
これが関数定義と矛盾するので、結果としてエラーになるわけです。この出力内で、コンパイラは問 
題を修正する手助けになりそうなメッセージも出していますね：セミコロンを削除するよう提言して 
います。そして、そうすれば、エラーは直るわけです。 

3.4 コメント 

全プログラマは、自分のコードがわかりやすくなるよう努めますが、時として追加の説明が許され 
ることもあります。このような場合、プログラマは注釈またはコメントをソースコードに残し、コメ 
ントをコンパイラは無視しますが、ソースコードを読む人間には有益なものと思えるでしょう。 

こちらが単純な コメントです： 

// hello , world 

Rust では、コメントは2連スラッシュで始め、行の終わりまで続きます。コメントが複数行にま 
たがる場合、各行に//を含める必要があります。こんな感じに： 

// So we ’ re doing something complicated here , long enough that we need 
// multi pie lines of comments to do it ! Whew ! Hopefully , this comment will 
// explain what ’ s going on . 

// ここで何か複雑なことをしていて、長すぎるから複数行のコメントが必要なんだ。 

// ふう！願わくば、このコメントで何が起きているか説明されていると嬉しい。 

コメントは、コードが書かれた行の末尾にも配置することができます： 

Filename : src / mam.rs 

fn main () { 

let lucky_number = 7; // I’m feeling lucky today (今日はラッキーな気がするよ 
) 

} 

しかし、こちらの形式のコメントの方が見かける機会は多いでしょう。注釈しようとしているコー 
ドの1行上に書く形式です： 

フアイル名： src / main.rs 

fn mann () { 

// I’m feeling lucky today 
// 今日はラッキーな気がするよ 
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Let lucky_number = 7; 

} 


Rust には他の種類のコメント、ドキュメントコメントもあり、それについては第14章で議論し 
ます。 


3.5 フロー制御 

条件が真かどうかによってコードを走らせるかどうかを決定したり、条件が真の間繰り返しコード 
を走らせるか決定したりすることは、多くのプログラミング言語において、基本的な構成ブロックで 
す。 Rust コードの実行フローを制御する最も一般的な文法要素は、 if 式とループです。 


3.5.1 if 式 

if 式によって、条件に依存して枝分かれをさせることができます。条件を与え、以下のように宣言 
します。「もし条件が合ったら、この一連のコードを実行しろ。条件に合わなければ、この一連のコー 
ドは実行するな」と。 

projects ディレクトリに branches という名のプロジェクトを作って if 式について掘り下げて 
いきましょう。 src / mam . rs ファイルに、以下のように入力してください： 

フアイル名： src / main.rs 

fn mann() { 

let number = 3; 

if number < 5 { 

println! ("condition was true") ; // 条件は真でした 

} else { 

println! ("condition was false") ; // 条件は偽でした 



if 式は全て、キーワードの if から始め、条件式を続けます。今回の場合、条件式は変数 number が 
5未満の値になっているかどうかをチヱックします。条件が真の時に実行したい一連のコードを条件 
式の直後に波かっこで包んで配置します。 if 式の条件式と紐付けられる一連のコードは、時として 
アームと呼ばれることがあります。第 2 章の「予想と秘密の数字を比較する」の節で議論した match 
式の アームと 同じです。 

オプションとして、 else 式を含むこともでき（ここではそうしています)、これによりプログラム 
は、条件式が偽になった時に実行するコードを与えられることになります。仮に、 else 式を与えずに 
条件式が偽になったら、プログラムは単に if ブロックを飛ばして次のコードを実行しにいきます。 

このコードを走らせてみましょう；以下のような出力を目の当たりにするはずです： 
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$ cargo run 

Compiling branches v0.1.0 (riLe:///proiects/branches) 

Finished dev [unoptimized + debuginfo] target(s) in 0.31 secs 
Running 'target/debug/branches' 
condition was true 


number の値を条件が false になるような値に変更してどうなるか確かめてみましょう： 
let number = 7; 


再度プログラムを実行して、出力に注目してください： 

5 cargo run 

Compiung branches v0.1.0 (file:///projects/branches) 

Finished dev [unoptimized + debuginfo] target(s) in 0.31 secs 
Running 'target/debug/branches' 
condition was false 

このコード内の条件式は、 bool 型でなければならないことにも触れる価値があります。条件式が、 
bool 型でない時は、エラーになります。例えば、試しに以下のコードを実行してみてください： 

フアイル名： src / main.rs 

fn mann() { 

let number = 3; 

if number { 

println! ("number was three") ; // 数値は 3 です 

} 


今回、 if の条件式は 3 という値に評価され、コンパイラがエラーを投げます: 


error[E0308] : mismatched types 
( 型が合いません） 
-- > src/main.rs :4:8 


4 


it number { 

aaaaaa expected bool, found integral variable 

(bool 型を予期したのに、整数変数が見つかりました） 


= note : expected tvpe bool 

found tvpe ^integer} 


このエラーは、 コンパイ ラは bool 型を予期していたのに、整数だったことを示唆しています 。 Ruby 
や JavaScript などの言語とは異なり、 Rust では、論理値以外の値が、自動的に論理値に変換される 
ことはありません。明示し、必ず if には条件式として、論理値を与えなければなりません。例えば、 
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数値が0以外の時だけ i f のコードを走らせたいなら、以下のように i f 式を変更することができます: 

フアイル名： src / main.rs 

fn mann() { 

let number = 3; 

if number != 0 { 

pri ntln! ("number was something other than zero") ; // 数値は 0 以外の何か 

です 

} 


このコードを実行したら、 number was something other than zero と表不されるでしよう。 

3.5.1.1 else " if で複数の条件を扱う 

if と else を組み合わせて else if 式にすることで複数の条件を持たせることもできます。例です: 

フアイル名： src / main.rs 

fn mann() { 

let number = 6; 


if number 96 4 == 0 { 

// 数値は 4 で割り切れます 

println ! ("number is divisible by 4") ; 

} else if number 96 3 == 0 { 

// 数値は 3 で割り切れます 

println ! ("number is divisible by 3") ; 

} else if number ?6 2 == 0 { 

// 数値は 2 で割り切れます 

println ! ("number is divisible by 2") ; 

} e Lse { 

// 数値は 4 、 3 、 2 で割り切れません 

println! ("number is not divisible by 4, 3, or 2") ; 



このプログラムには、通り道が 4 つあります。実行後、以下のような出力を目の当たりにするはず 
です： 

$ cargo run 

Compiling branches v0.1.0 (file:///proiects/branches) 

Finished dev [unoptimized + debuginfo] target(s) in 0.31 secs 
Running 'target/debug/branches' 
number is divisible by 3 


このプログラムを 実行すると、 if 式が順番に吟味され、最初に条件が真になった本体が実行され 
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ます。 6 は 2 で割り切れるものの、 number is devisible by 2 や、 else ブロックの number i s not 
divisible by 4, 3, or 2 という出力はされないことに注目してください。それは、 Rust が最初の 
真条件のブロックのみを実行し、条件に合ったものが見つかったら、残りはチヱックすらしないから 
です。 

else if 式を使いすぎると、コードがめちゃくちゃになってしまうので、 1 つ以上あるなら、コー 
ドをリファクタリングしたくなるかもしれません。これらのケースに有用な match と呼ばれる、強力 
な Rust の枝分かれ文法要素については第6章で解説します。 


3.5.1.2 let 文内で if 式を使う 

if は式なので、 let 文の右辺に持ってくることができます。リスト 3-2 のようにですね。 

フアイル名： src / main.rs 

fn mann() { 

let condition = true ; 

let number = if condition { 

5 

} else { 

6 

}； 


// number の値は、 {] ■です 

println! ("The value of number is: {}" , number); 

} 

リスト 3-2: if 式の結果を変数に代入する 

この number 変数は、 if 式の結果に基づいた値に束縛されます。このコードを走らせてどうなるか 
確かめてください： 

$ cargo run 

Compiling branches v0.1.0 (file:///proiects/branches) 

Finished dev [unoptimized + debuginfo] target(s) in 0.30 secs 
Running 'target/debug/branches' 

The value of number is: 5 

一連のコードは、そのうちの最後の式に評価され、数値はそれ単独でも式になることを思い出して 
ください。今回の場合、この if 式全体の値は、どのブロックのコードが実行されるかに基づきます。 
これはつまり、 if の各アームの結果になる可能性がある値は、同じ型でなければならないということ 
になります；リスト 3-2 で、 if アームも else アームも結果は、 i32 の整数でした。以下の例のよう 
に、型が合わない時には、エラーになるでしょう： 


ファイル名： src / main.rs 
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fn mann() i 

let condition = true : 

let number 二 if condition { 
5 

} else { 

"six" 

}； 


println! ("The value of number is: {}" , number); 

} 


このコードをコンパイルしようとすると、エラーになります。 if と else アームは互換性のない値 
の型になり、コンパイラがプログラム内で問題の見つかった箇所をスバリ指摘してくれます： 


error*[E0308] : it and else nave incompatiole types 
(if と else の型に互換性がありません） 
-- > src/main.rs :4:18 


4 


let number =if condition { 


5 

} else { 

"six" 

}； 

,expected integral variable, found &str 

( 整数変数を予期しましたが、 &str が見つかりました） 

= note : expected tvpe nteger}' 
found tvpe &str 


5 

6 

7 

8 


if ブロックの式は整数に評価され、 else ブロックの式は文字列に評価されます。これでは動作し 
ません。変数は単独の型でなければならないからです。コンパイラは、コンパイル時に number 変数 
の型を確実に把握する必要があるため、コンパイル時に number が使われている箇所全部で型が有効 
かどうか検査することができるのです。 number の型が実行時にしか決まらないのであれば、コンパイ 
ラはそれを実行することができなくなってしまいます；どの変数に対しても、架空の複数の型がある 
ことを追いかけなければならないのであれば、コンパイラはより複雑になり、コードに対して行える 
保証が少なくなってしまうでしょう。 


3.5.2 ループでの 繰り返し 

一連のコードを 1 回以上実行できると、しばしば役に立ちます。この作業用に、 Rust にはいくつ 
かのループが用意されています。ループは、本体内のコードを最後まで実行し、直後にまた最初から 
処理を開始します。ループを試してみるのに、 loops という名の新プロジェクトを作りましょう。 
Rust には 3 種類のループが存在します： 10 op と while と for です。それぞれ試してみましよう。 
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3.5.2. 1 loop でコー ドを繰り返す 

loop キーワードを使用すると、同じコードを何回も何回も永遠に、明示的にやめさせるまで実行し 
ます。 

例として、 loops ディレクトリの src / main . rs ファイルを以下のような感じに書き換えてくだ 
さい： 

フアイル名： src / main.rs 

fn mann () { 
loop { 

pri ntln ! ("agai n ! ") ; //また 

} 

} 

このプログラムを実行すると、プログラムを手動で止めるまで、何度も何度も続けて again ! と出力 
するでしょう。ほとんどの端末で ctrl - c というショートカットが使え、永久ループに囚われてしまっ 
たプログラムを終了させられます。試しにやってみましょう： 

$ cargo run 

Compiling Loops v 0.1.0 (tn ie :/// projects / loops ; 

Finished dev [unoptimized + debuginfo ] target ( s ) in 0.29 secs 
Running ' target / debug / loops ' 
again ! 
again ! 
again ! 
again ! 

A Cagain ! 

A C という記号が出た場所が、 Ctrl - C を押した場所です。 A C の後には again ! と表示されたり、され 
なかったりします。ストップシグナルをコードが受け取った時にループのどこにいたかによります。 

幸いなことに、 Rust にはループを抜け出す別のより信頼できる手段があります。ループ内に break 
キーワードを配置することで、プログラムに実行を終了すべきタイミングを教えることができます。 
第2章の「正しい予想をした後に終了する」節の数当てゲーム内でこれをして、ユーザが予想を的中 
させ、ゲームに勝った時にプログラムを終了させたことを思い出してください。 

3.5.2.2 while で条件付きループ 

プログラムにとってループ内で条件式を評価できると、有益なことがしばしばあります。条件が真 
の間、ループが走るわけです。条件が真でなくなった時にプログラムは break を呼び出し、ループを 
終了します。このタイプのループは、 100 p 、 if 、 else 、 break を組み合わせることでも実装できま 
す；お望みなら、プログラムで今、試してみるのもいいでしょう。 

しかし、このパターンは頻出するので、 Rust にはそれ用の文法要素が用意されていて、 whUe ルー 
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プと呼ばれます。リスト 3-3 は、 while を使用しています：プログラムは3回ループし、それぞれ力 
ウントダウンします。それから、ループ後に別のメッセージを表示して終了します： 

フ アイ ル名： src / main.rs 

fn mann () { 

let mut number = 3; 

while number != 0 { 

println !("{}!" ， number ); 

number = number - 1; 

} 

// 発射！ 

println ! (" LIFTOFF !!! ") ; 

} 

リスト 3-3: 条件が真の間、コードを走らせる while ループを使用する 

この文法要素により、 100 p 、 if 、 else 、 break を使った時に必要になるネストがなくなり、より 
明確になります。条件が真の間、コードは実行されます；そうでなければ、ループを抜けます. 

3.5.2.3 for でコレクションを覗き見る 

while 要素を使って配列などのコレクションの要素を覗き見ることができます。例えば、リスト 3-4 
を見ましょう。 

フ アイ ル名： src / main.rs 

fn mann () { 

let a =[10, 20, 30, 40, 50]; 
let mut index = 0; 

while index < 5 { 

// 値は {} です 

println! ("the value is : {}" , a [ index ]); 
index = index + 1; 

} 

} 


リスト 3-4： while ループでコレクシヨンの各要素を覗き見る 


ここで、コードは配列の要素を順番にカウントアップして覗いています。番号0から始まり、配列 
の最終番号に到達するまでループします（つまり、 index < 5 が真でなくなる時です)。このコードを 
走らせると、配列内の全要素が出力されます： 
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5 cargo run 

Compiung loops v 0.1.0 (ri ie :/// projects / loops ) 

Finished dev [unoptimized + debuginfo ] target ( s ) in 0.32 secs 
Running ' target / debug / loops ' 
the value is :10 
the value is : 20 
the value is : 30 
the value is : 40 
the value is : 50 

予想通り、配列の 5 つの要素が全てターミナルに出力されています。 index 変数の値はどこかで5 
という値になるものの、配列から6番目の値を拾おうとする前にループは実行を終了します。 

しかし、このアプローチは間違いが発生しやすいです；添え字の長さが間違っていれば、プログラム 
はパニックしてしまいます。また遅いです。コンパイラが実行時にループの各回ごとに境界値チェッ 
クを行うようなコードを追加するからです。 

より効率的な対立案として、 for ループを使ってコレクションの各アイテムに対してコードを実行 
することができます。 for ループはリスト 3-5 のこんな見た目です。 

フアイル名： src / main.rs 
fn mann () { 

let a =[10, 20, 30, 40, 50]; 

for element in a . iter () { 

// 値は {} です 

println! ("the value is : {}" , element ); 



リスト 3-4： for ループを使ってコレクシヨンの各要素を覗き見る 


このコードを走らせたら、リスト 3-4 と同じ出力が得られるでしょう。より重要なのは、コードの 
安全性を向上させ、配列の終端を超えてアクセスしたり、終端に届く前にループを終えてアイテムを 
見逃してしまったりするバグの可能性を完全に排除したことです。 

例えば、リスト 3-4 のコードで、 a 配列からアイテムを1つ削除したのに、条件式を while index 
< 4 にするのを忘れていたら、コードはパニックします。 for ループを使っていれば、配列の要素数 
を変えても、他のコードをいじることを覚えておく必要はなくなるわけです。 

for ループのこの安全性と簡潔性により、 Rust で使用頻度の最も高いループになっています。リス 
卜 3-3 で while ループを使ったカウントダウンサンプルのように、一定の回数、同じコードを実行し 
たいような状況であっても、多くの Rustacean は、 for ループを使うでしょう。どうやってやるか 
といえば、 Range 型を使うのです。 Range 型は、標準ライブラリで提供される片方の数字から始まっ 
て、もう片方の数字未満の数値を順番に生成する型です。 

for ループと、まだ話していない別のメソッド rev を使って範囲を逆順にしたカウントダウンはこ 



第 3 章一般的なプログラミングの概念 


60 


うなります： 

フアイル名： src / main.rs 
fn main () { 

tor number in (1..4). rev () { 
println ! ("{} !" , number ); 

} 

println ! (" LIFTOFF !!! ") ; 

} 

こちらのコードの方が少しいいでしょう？ 

3.6 まとめ 

やりましたね！結構長い章でした：変数、スカラー値と複合データ型、関数、コメント、 if 式、そ 
して、ループについて学びました！この章で議論した概念について経験を積みたいのであれば、以下 
のことをするプログラムを組んでみてください： 

• 温度を華氏と摂氏で変換する。 

• フィボナッチ数列の n 番目を生成する。 

•クリスマス キャロルの 定番 、” The Twelve Days of Christmas ” の 歌詞を、曲の反復性を利 
用して出力する。 

次に進む準備ができたら、他の言語にはあまり存在しない Rust の概念について話しましょう：所有 
権です。 
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第 


早 


所有権を理解する 


所有権は Rust の最もユニークな機能であり、これのおかげでガベー ジコ レクタなしで安全性担保 
を行うことができるのです。故に、 Rust において、所有権がどう動作するのかを理解するのは重要で 
す。この章では、所有権以外にも、関連する機能をいくつか話していきます：借用、スライス、そし 
て、 コンパイ ラがデータをメモリにどう配置するかです。 

4.1 所有権とは？ 

Rust の中心的な機能は、所有権です。機能は説明するのに単純なのですが、言語の残りの機能全て 
にかかるほど深い裏の意味を含んでいるのです。 

全てのプログラムは、実行中にコンピュータのメモリの使用方法を管理する必要があります。プロ 
グラムが動作するにつれて、定期的に使用されていないメモリを検索するガベージコレクションを持 
つ言語もありますが、他の言語では、プログラマが明示的にメモリを確保したり、解放したりしなけ 
ればなりません。 Rust では第3の選択肢を取っています：メモリは、コンパイラがコンパイル時に 
チェックする一定の規則とともに所有権システムを通じて管理されています。どの所有権機能も、実 
行中にプログラムの動作を遅くすることはありません。 

所有権は多くのプログラマにとって新しい概念なので、慣れるまでに時間がかかります。 Rust と所 
有権システムの規則と経験を積むにつれて、自然に安全かつ効率的なコードを構築できるようになる 
ことは、素晴らしいお知らせです。その調子でいきましょう！ 

所有権を理解した時、 Rust を際立たせる機能の理解に対する強固な礎を得ることになるでしょう。 
この章では、非常に一般的なデータ構造に着目した例を取り扱うことで所有権を学んでいきます：文 
字列です。 
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4.1.1 スタックとヒープ 

多くのプログラミング言語において、スタックとヒープについて考える機会はそう多くないで 
しょう。しかし、 Rust のようなシステムプログラミング言語においては、値がスタックに載る 
かヒープに載るかは、言語の振る舞い方や、特定の決断を下す理由などに影響以上のものを与 
えるのです。この章の後半でスタックとヒープを絡めて所有権の一部は解説されるので、ここ 
でちょっと予行演習をしておきましょう。 

スタックもヒープも、実行時にコードが使用できるメモリの一部になりますが、異なる手段で 
構成されています。スタックは、得た順番に値を並べ、逆の順で値を取り除いていきます。こ 
れは 、 last in , first out (訳注：あえて日本語にするなら、けつ入れ頭出しといったところで 
しょうか）と呼ばれます。お皿の山を思い浮かべてください：お皿を追加する時には、山の一番 
上に置き、お皿が必要になったら、一番上から1枚を取り去りますよね。途中や一番下に追加 
したり、取り除いたりすることもできません。データを追加することは、スタックに push す 
るといい、データを取り除くことは、スタックから pop すると表現します（訳注：日本語では 
単純に英語をそのまま活用してプッシュ、ポップと表現するでしょう）。 

データへのアクセス方法のおかげで、スタックは高速です：新データを置いたり、データを取 
得する場所を探す必要が絶対にないわけです。というのも、その場所は常に一番上だからです 
ね。スタックを高速にする特性は他にもあり、それはスタック上のデータは全て既知の固定サ 
イズにならなければならないということです。 

コンパイル時にサイズがわからなかったり、サイズが可変のデータについては、代わりにヒー 
プに格納することができます。ヒープは、もっとごちゃごちゃしています：ヒープにデータを 
置く時、あるサイズのスペースを求めます。 0 S はヒープ上に十分な大きさの空の領域を見つ 
け、使用中にし、ポインタを返してきます。ポインタとは、その場所へのアドレスです。この 
過程は、ヒープに領域を確保すると呼ばれ、時としてそのフレーズを単に allocate するなど 
と省略したりします。（訳注：こちらもこなれた日本語訳はないでしょう。 allocate はメモリを 
確保すると訳したいところですが）スタックに値を載せることは、メモリ確保とは考えられま 
せん。ポインタは、既知の固定サイズなので、スタックに保管することができますが、実デー 
夕が必要になったら、ポインタを追いかける必要があります。 

レストランで席を確保することを考えましょう。入店したら、グループの人数を告げ、店員が 
全員座れる空いている席を探し、そこまで誘導します。もしグループの誰かが遅れて来るのな 
ら、着いた席の場所を尋ねてあなたを発見することができます。 

ヒープへのデータアクセスは、スタックのデータへのアクセスよりも低速です。ポインタを 
追って目的の場所に到達しなければならないからです。現代のプロセッサは、メモリをあちこ 
ち行き来しなければ、より速くなります。似た例えを続けましょう。レストランで多くのテー 
ブルから注文を受ける給仕人を考えましょう。最も効率的なのは、次のテーブルに移らずに、 
一つの テーブルで全部の注文を受け付けてしまうことです。テーブル A で注文を受け、それか 
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らテーブル B の注文、さらにまた A 、 それからまた B と渡り歩くのは、かなり低速な過程に 
なってしまうでしょう。同じ意味で、プロセッサは、データが隔離されている（ヒープではそ 
うなっている可能性がある）よりも近くにある（スタックではこうなる）ほうが、仕事をうまく 
こなせるのです。ヒープに大きな領域を確保する行為も時間がかかることがあります。 

コードが関数を呼び出すと、関数に渡された値（ヒープのデータへのボインタも含まれる可能 
性あり）と、関数のローカル変数がスタックに載ります。関数の実行が終了すると、それらの 
値はスタックから取り除かれます。 

どの部分のコードがどのヒープ上のデータを使用しているか把握すること、ヒープ上の重複す 
るデータを最小化すること、メモリ不足にならないようにヒープ上の未使用のデータを掃除す 
ることは全て、所有権が解決する問題です。一度所有権を理解したら、あまり頻繁にスタック 
とヒープに関して考える必要はなくなるでしょうが、ヒープデータを管理することが所有権の 
存在する理由だと知っていると、所有権がありのままで動作する理由を説明するのに役立つこ 
ともあります。 


4.1.2 所有権規則 

まず、所有権の ルールに ついて見ていきましょう。この規則を具体化する例を扱っていく間もこれ 
らの ルールを 肝に銘じておいてください： 

• Rust の各値は、所有者と呼ばれる変数と対応している。 

• いかなる時も所有者は 一つで ある。 

• 所有者がスコープから外れたら、値は破棄される。 


4.1.3 変数スコープ 

第2章で、 Rust プログラムの例はすでに見ています。もう基本的な記法は通り過ぎたので 、 fn 
main () { というコードはもう例に含みません。従って、例をなぞっているなら、これからの例は main 
関数に手動で入れ込まなければいけなくなるでしょう。結果的に、例は少々簡潔になり、定型コード 
よりも具体的な詳細に集中しやすくなります。 

所有権の最初の例として、何らかの変数の スコープについて 見ていきましょう。スコープとは、要 
素が有効になるプログラム内の範囲のことです。以下のような変数があるとしましょう： 

let s = " hello " ; 

変数 S は、文字列リテラルを参照し、ここでは、文字列の値はプログラムのテキストとしてハード 
コードされています。この変数は、宣言された地点から、現在のスコープの終わりまで有効になりま 
す。リスト 4-1 には、変数 S が有効な場所に関する注釈がコメントで付記されています。 
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{ // S は、ここでは有効ではない。まだ宣言されていない 

let s = " hello " ; // s は、ここから有効になる 

// s で作業をする 

} // このスコープは終わり。もう s は有効ではない 

リスト 4-1: 変数と有効なスコープ 

言い換えると、ここまでに重要な点は二つあります： 

• s がスコープに入ると、有効になる 
• スコープを抜けるまで、有効なまま 

ここで、スコープと変数が有効になる期間の関係は、他の言語に類似しています。さて、この理解 
のもとに、 String 型を導入して構築していきましょう。 

4.1.4 String 型 

所有権の規則を具体化するには、第3章の「データ型」節で講義したものよりも、より複雑なデー 
夕型が必要になります。以前講義した型は全てスタックに保管され、スコープが終わるとスタックか 
ら取り除かれますが、ヒープに確保されるデータ型を観察して、コンパイラがどうそのデータを掃除 
すべきタイミングを把握しているかを掘り下げていきたいです。 

ここでは、例として String 型を使用し、 String 型の所有権にまつわる部分に着目しましょう。ま 
た、この観点は、標準ライブラリや自分で生成する他の複雑なデータ型にも適用されます。 String 型 
について は、第8章でより深く議論します。 

既に文字列リテラルは見かけましたね。文字列リテラルでは、文字列の値はプログラムにハード 
コードされます。文字列リテラルは便利ですが、テキストを使いたいかもしれない場面全てに最適な 
わけではありません。一因は、文字列リテラルが不変であることに起因します。別の原因は、コード 
を書く際に、全ての文字列値が判明するわけではないからです：例えば、ユーザ入力を受け付け、そ 
れを保持したいとしたらどうでしょうか？このような場面用に、 Rust には、2種類目の文字列型、 
String 型があります。この型はヒープにメモリを確保するので、コンパイル時にはサイズが不明なテ 
キストも保持することができるのです。 from 関数を使用して、文字列リテラルから String 型を生成 
できます。以下のように： 

let s = String : : f rom (" hello ") ; 

この二重 コロンは、 stHng_f rom などの名前を使うのではなく 、 Stri ng 型直下の f rom 関数を特定 
する働きをする演算子です。この記法に ついて 詳しくは、第5章の「メソッド記法」節と、第7章の 
「モジュール定義」でモジュールを使った名前空間分けに ついて 話をするときに議論します。 

この種の文字列は、可変化することができます： 
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let mut s = String: : f rom("heLlo") ; 

s. push_str(" , world!"); // push_str () 関数は、リテラルを String に付け加える 
pri ntln! ("{}", s); // これは、 hello, world !、 と出力する 

では、ここでの違いは何でしょうか？なぜ、 String 型は可変化できるのに、リテラルはできない 
のでしょうか？違いは、これら二つの型がメモリを扱う方法にあります。 

4.1.5 メモリと確保 

文字列リテラルの場合、中身はコンパイル時に判明しているので、テキストは最終的なバイナリ 
ファイルに直接ハードコードされます。このため、文字列リテラルは、高速で効率的になるのです。 
しかし、これらの特性は、その文字列リテラルの不変性にのみ端を発するものです。残念なことに、 
コンパイル時にサイズが不明だったり、プログラム実行に合わせてサイズが可変なテキスト片用に一 
塊のメモリをバイナリに確保しておくことは不可能です。 

String 型では、可変かつ伸長可能なテキスト破片をサボートするために、コンパイル時には不明な 
量のメモリをヒープに確保して内容を保持します。つまり： 

• メモリは、実行時に 0 S に要求される。 

• String 型を使用し終わったら、 0 S にこのメモリを返還する方法が必要である。 

この最初の部分は、既にしています： String: :from 関数を呼んだら、その実装が必要なメモリを要 
求するのです。これは、プログラミング言語において、極めて普遍的です。 

しかしながら、2番目の部分は異なります。ガベージコレクタ （ GC ) 付きの言語では、 GC がこれ以 
上、使用されないメモリを検知して片付けるため、プログラマは、そのことを考慮する必要はありま 
せん。 GC がないなら、メモリがもう使用されないことを見計らって、明示的に返還するコードを呼び 
出すのは、プログラマの責任になります。ちょうど要求の際にしたようにですね。これを正確にする 
ことは、歴史的にも難しいプログラミング問題の一つであり続けています。もし、忘れていたら、メモ 
リを無駄にします。タイミングが早すぎたら、無効な変数を作ってしまいます。2回解放してしまっ 
ても、バグになるわけです。 allocate と free は完璧に 1 対 1 対応にしなければならないのです。 

Rust は、異なる道を歩んでいます：ひとたび、メモリを所有している変数がスコープを抜けたら、メ 
モリは自動的に返還されます。こちらの例は、リスト 4-1 のスコープ例を文字列リテラルから String 
型を使うものに変更したバージョンになります： 

{ 

let s = String: : from("hello") ; // s はここから有効になる 


} 


// s で作業をする 


// このスコープはここでおしまい。 s は 
//もう有効ではない 
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String 型が必要とするメモリを 0 S に返還することが自然な地点があります： s 変数がスコープを 
抜ける時です。変数がスコープを抜ける時、 Rust は特別な関数を呼んでくれます。この関数は、 drop 
と呼ばれ、ここに String 型の書き手はメモリ返還するコードを配置することができます。 Rust は、 
閉じ波括弧で自動的に drop 関数を呼び出します。 

注釈： C ++ では、要素の生存期間の終了地点でリソースを解放するこのパターンを時に、 
RAII(Resource Aquisition Is Initialization: リソースの獲得は、初期化である）と呼んだ 
りします。 Rust の drop 関数は、あなたが RAII パターンを使ったことがあれば、馴染み深い 
ものでしよう。 

このパターンは、 Rust コードの書かれ方に甚大な影響をもたらします。現状は簡単そうに見えるか 
もしれませんが、ヒープ上に確保されたデータを複数の変数に使用させるようなもっと複雑な場面で 
は、コードの振る舞いは、予期しないものになる可能性もあります。これから、そのような場面を掘 
り下げてみましょう。 

4.1.5. 1変数とデータの相互作用 法： ムーブ 

Rust においては、複数の変数が同じデータに対して異なる手段で相互作用することができます。整 
数を使用したリスト 4-2 の例を見てみましょう。 

let x = 5; 
let v = x; 

リスト 4-2： 変数 x の整数値を y に代入する 

もしかしたら、何をしているのか予想することができるでしょう：「値 5 を x に束縛する；それから 
x の値を コピーして y に束縛する。」これで、二つの変数 （x と y) が存在し、両方、値は 5 になりまし 
た。これは確かに起こっている現象を説明しています。なぜなら、整数は既知の固定サイズの単純な 
値で、これら二つの 5 という値は、スタックに積まれるからです。 

では、 String バージョンを見ていきましよう： 

let si = String: : from("hello") ; 
let s2 = si; 

このコードは先ほどのコードに酷似していますので、動作方法も同じだと思い込んでしまうかもし 
れません：要するに、2行目で si の値をコピーし、 s 2 に束縛するということです。ところが、これは 
全く起こることを言い当てていません。 

図 4-1 を見て、ベールの下で String に何が起きているかを確かめてください。 String 型は、左側 
に示されているように、3つの部品でできています：文字列の中身を保持するメモリへのポインタと 
長さ、そして、許容量です。この種のデータは、スタックに保持されます。右側には、中身を保持し 
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たヒープ上のメモリがあります。 


si 



図 4-1: si に束縛された” hello " という値を保持する String のメモリ上の表現 

長さは、 String 型の中身が現在使用しているメモリ量をバイトで表したものです。許容量は 、 String 
型が OS から受け取った全メモリ量をバイトで表したものです。長さと許容量の違いは問題になるこ 
とですが、この文脈では違うので、とりあえずは、許容量を無視しても構わないでしょう。 

si を S 2 に代入すると、 String 型のデータがコピーされます。つまり、スタックにあるポインタ、 
長さ、許容量をコピーするということです。ポインタが指すヒープ上のデータはコピーしません。言 
い換えると、メモリ上のデータ表現は図 4-2 のようになるということです。 


Si 



図 4-2: si のポインタ、長さ、許容量のコピーを保持する変数 s 2 のメモリ上での表現 

メモリ上の表現は、図 4-3 のようにはなりません。これは、 Rust が代わりにヒープデータもコピー 
するという選択をしていた場合のメモリ表現ですね。 Rust がこれをしていたら、ヒープ上のデータが 
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大きい時に S 2 = si という処理の実行時性能がとても悪くなっていた可能性があるでしょう。 


Si 
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図 4-3: Rust がヒープデータもコピーしていた場合に s2 = si という処理が行なった可能性のある 
こと 

先ほど'、変数がスコープを抜けたら、 Rust は自動的に drop 関数を呼び出し、その変数が使ってい 
たヒープメモリを片付けると述べました。しかし、図 4-2 は、両方のデータポインタが同じ場所を指 
していることを示しています。これは問題です： S 2 と si がスコープを抜けたら、両方とも同じメモ 
リを解放しようとします。これは二重解放エラーとして知られ、以前触れたメモリ安全性上のバグの 
一つになります。メモリを2回解放することは、メモリの退廃につながり、さらにセキュリティ上の 
脆弱性を生む可能性があります。 

メモリ安全性を保証するために、 Rust においてこの場面で起こることの詳細がもう一つあります。 
確保されたメモリをコピーしようとする代わりに、コンパイラは、 S 1 が最早有効ではないと考え、故 
に S 1 がスコープを抜けた際に何も解放する必要がなくなるわけです。 S 2 の生成後に S 1 を使用しよう 
としたら、どうなるかを確認してみましょう。動かないでしょう： 

let si = String : : from (" hello ") ; 

let s 2 = si ; 

println ! ("{} , world !", si ); 


コンパイラが無効化された参照は使用させてくれないので、以下のようなエラーが出るでしょう： 
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error[E0382] : use of moved value: si 

( ムーブされた値の使用： 、 sl') 
——> src/main.rs :5:28 


3 | let s2 = si; 

I —— va Lue moved here 


5 | println! ("{}, world!’ 1 ， si); 

| AA value used here after move 

| ( ムーブ後にここで使用されています） 

I 

= note : move occurs because 'si' has type 'std: : string: : String', which does 
not implement the 'Copy' trait 

( 注釈：ムーブが起きたのは、 'si' が ' std: : string: : String ' という 
'Copy' トレイトを実装していない型だからです） 


他の言語を触っている間に” shallow copy ” と” deep copy ” という用語を耳にしたことがあるな 
ら、データのコピーなしにポインタと長さ、許容量をコピーするという概念は 、 shallow copy のよ 
うに思えるかもしれません。ですが、コンパイラは最初の変数をも無効化するので 、 shallow copy 
と呼ばれる代わりに、ムーブとして知られているわけです。この例では、 si は S 2 にムーブされたと 
表現するでしょう。以上より、実際に起きることを図 4-4 に示してみました。 


si 



図 4-4: si が無効化された後のメモリ表現 

これにて一件落着です。 S 2 だけが有効なので、スコープを抜けたら、それだけがメモリを解放し 
て、終わりになります。 

付け加えると、これにより暗示される設計上の選択があります： Rust では、自動的にデータの ” deep 
copy ” が行われることは絶対にないわけです。それ故に、あらゆる自動コピーは、実行時性能の観点 
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で言うと、悪くないと考えてよいことになります。 

4.1.5.2変数とデータの相互作用法：クローン 

仮に、スタック上のデータだけでなく、本当に string 型のヒープデータの deep copy が必要なら 
ば、 clone と呼ばれるよくあるメソッドを使うことができます。メソッド記法については第5章で議 
論しますが、メソッドは多くのプログラミング言語に見られる機能なので、以前に見かけたこともあ 
るんじやないでしょうか。 

こちらで、 clone メソッドの稼働例をご覧ください： 

let si = String : : from (" hello ") ; 
let s 2 = sl . clone () : 

pn ' ntln !(" sl = {}, s 2 = {}" , si , s 2); 

これは単純にうまく動き、図 4-3 で示した動作を明示的に生み出します。ここでは、ヒープデータ 
が実際にコピーされています。 

clone メソッドの呼び出しを見かけたら、何らかの任意のコードが実行され、その実行コストは高 
いと把握できます。何か違うことが起こっているなと見た目でわかるわけです。 

4.1.5.3 スタックのみのデータ：コピー 

まだ話題にしていない別のしわ（訳注：「気になるもの」程度の意味と思われる）の話があります。こ 
の整数を使用したコードは、一部をリスト 4-2 で示しましたが、うまく動作し、合法です： 

let x = 5; 
let v = x ; 

println! ("x = {}, y = {}", x , y ); 

ですが、このコードは一見、今学んだことと矛盾しているように見えます： clone メソッドの呼び 
出しがないのに、 x は有効で、 y にムーブされませんでした。 

その理由は、整数のようなコンパイル時に既知のサイズを持つ型は、スタック上にすっぽり保持さ 
れるので、実際の値をコピーするのも高速だからです。これは、変数 y を生成した後にも x を無効化 
したくなる理由がないことを意味します。換言すると、ここでは、 shallow copy と deep copy の 
違いがないことになり、 clone メソッドを呼び出しても、一般的な shallow copy 以上のことをしな 
くなり、そのまま放置しておけるということです。 

Rust には Copy トレイトと呼ばれる特別な注釈があり、整数のようなスタックに保持される型に対 
して配置することができます（トレイトについては第10章でもっと詳しく話します)。型が Copy 卜 
レイトに適合していれば、代入後も古い変数が使用可能になります。コンパイラは、型やその一部分 
でも Drop トレイトを実装している場合、 Copy トレイトによる注釈をさせてくれません。型の値がス 
コープを外れた時に何か特別なことを起こす必要がある場合に、 Copy 注釈を追加すると、コンパイル 
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エラーが出ます。型に Copy 注釈をつける方法について学ぶには、付録 C の「継承可能トレイト」を 
ご覧ください。 

では、どの型が Copy なのでしょうか？ある型について、ドキュメントをチヱックすればいいので 
すが、一般規則として、単純なスカラー値の集合は何でも Copy であり、メモリ確保が必要だったり、 
何らかの形態のリソースだったりするものは Copy ではありません。ここに Copy の型の一部を並べて 
おきます。 

• あらゆる整数型。 U 32 など。 

• 論理値型、 bool 、 true と false という値がある 0 
• あらゆる浮動小数点型、 f 64など。 

• 文字型、 char 。 

• タプル。ただ、 Copy の型だけを含む場合。例えば、 ( i 32, i 32) は Copy だが、 ( i 32, String ) 
は違う。 


4.1.6 所有権と関数 

意味論的に、関数に値を渡すことと、値を変数に代入することは似ています。関数に変数を渡すと、 
代入のようにムーブやコピーされます。リスト 4-3 は変数がスコープに入ったり、抜けたりする地点 
について注釈してある例です。 


フアイル名： src / mam.rs 


fn mann () i 

let s = String : : f rom (" hello ") ; // s がスコープに入る 


takes _ ownership (. s ; ; 

// 


// 

let x = 5; 

// 

makes _ copy ( x ); 

// 


// 


// 


s の値が関数にムーブされ... 

... ここではもう有効ではない 

x がスコープに入る 

x も関数にムーブされるが、 

i 32 は Copy なので、この後に x を使っても 

大丈夫 


} //ここで父がスコープを抜け、 s も。だけど、 s の値はムーブされてるので、何も特別な 
ことはない。 

// 


fn takes_ownershi p ( some_stn ng : String ) { // some _ str]ng 力 5 スコーフに入る。 
pnntln ! ("{}", some _ stnng ) : 

} // ここで some _ str*ing がスコープを抜け、 ' drop ' が呼ばれる。後ろ盾してたメモリが解 
放される。 

// 


fn maKes_copy ( some_T nteger : i 32) { // some _ integer * 力 5 スコーフに入る 
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pnntln ! ("{}", some_integer) ; 

} // ここで some_integer がスコープを抜ける。何も特別なことはない。 


リスト 4-3: 所有権 とスコー プが注釈された関数群 


takes_ownership の呼び出し後に s を 呼び出そうとすると、 コンパイラは、コンパイルエラーを 投 
げるでしょう。これらの静的チヱックにより、ミスを犯さないでいられます。 s や x を使用するコー 
ドを main に追加してみて、どこで使えて、そして、所有権規則により、どこで使えないかを確認して 
ください。 

4.1.7 戻り値と スコープ 

値を返すことでも、所有権は移動します。リスト 4-4 は、リスト 4-3 と似た注釈のついた例です。 
フアイル名： src / main.rs 
fn mann () { 

let si=gives_ownershi p () ; // gi . ves_ownershi p t ま、民り値を sit こ 

// ムーブ する 

let s 2 = String : : f rom (" hello ") ; // s 2 がスコープに入る 

let s 3 = takes _ and_gi ves _ back ( s 2) ; // s 21 ま takes _ and _ gi . ves_back に ムーブ され 

// 戻り値も s3 にムーブされる 

}// ここで、 S3 はスコープを抜け、ドロップされる。 s2 もスコープを抜けるが、ムーブ 
されているので、 

// 何も起きない。 si もスコープを抜け、ドロップされる。 

fn g ] ves_ownershi p () -> String { // gi ves_ownershi p は、民り値を 

// 呼び出した関数にムーブする 

let some_string = Stri ng : : f rom (" hello ") ; // some_stri ng がスコープに入る 

some_stri ng // some_stri ng が返され、呼び出し元 

関数に 


// takes 一 and_gives_back は 、 String を一つ受け取り、返す。 

fn takes_and_gi ves_back(a_stn ng: String) -> String { // a_string 力 5 スコーフに入 

る。 

a_string // a_string が返され、呼び出し元関数にムーブされる 

} 

リスト 4-4: 戻り値の所有権を移動する 

変数の所有権は、毎回同じパターンを迪っています：別の変数に値を代入すると、ムーブされます。 
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ヒープにデータを 含む変数がス コープを 抜けると、 データ が別の変数に所有されるよう ムーブ されて 
いない限り、 drop により片付けられるでしょう。 

所有権を得ては返すを全ての関数でしていたら、ちょっとめんどくさいですね。関数に値を使わせ 
たいけど、所有権は保持させたくない場合はどうすればいいのでしょうか？返したいと思うかもしれ 
ない関数本体で発生したあらゆるデータとともに、再利用したかったら、渡されたものをまた返さな 
きゃいけないのは、非常に煩わしいことです。 

タプルで、複数の値を返すことは可能です。リスト 4-5 のようにですね。 

フ アイ ル名： src / main.rs 

fn mann () { 

let si = String : : f rom (" hello ") ; 
let ( s 2, len ) = calculate _ length ( si ); 

の長さは、です 

println! ("The length of '{}' is , s 2, len ); 

} 

fn calculate _ length ( s : Stri ng ) -> ( String , usize ) { 

let length = s . len (); // len () メソッドは、 String の長さを返します 


(s, length) 

} 


リスト 4-5: 引数の所有権を返す 


でも、これでは、大袈裟すぎますし、ありふれているはずの概念に対して、作業量が多すぎます。 
私たちにとって幸運なことに、 Rust にはこの概念に対する機能があり、参照と呼ばれます。 

4.2 参照と借用 

リスト 4-5 のタプルコードの問題は、 String 型を呼び出し元の関数に戻さないと、 
calculate_length を呼び出した後に、 String オブジヱクトが使えなくなることであり、これ 
は String オブジヱクトが calculate_length にムー ブされてしまうためでした。 

ここで、値の所有権をもらう代わりに引数としてオブジェクトへの参照を取る calculate_length 
関数を定義し、使う方法を見てみましょう： 

フアイル名： src / main.rs 

fn mann() { 

let si= Stri ng: : from ("hello") ; 


let len = calculate_length(&sl); 
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// •{}’ の長さは、 {} です 

println ! ("The length of '{}' is , si, len); 

} 

fn calculate_Length(s: &String) -> usize { 
s.len () 

} 

まず、変数宣言と関数の戻り値にあったタプルコードは全てなくなったことに気付いてください。 
2杳目に、 &sl を calcuate_length に渡し、その定義では、 String 型ではなく、 &Str*ing を受け取っ 
ていることに注目してください。 

これらのアンド記号が参照であり、これのおかげで所有権をもらうことなく値を参照することがで 
きるのです。図 4-5 はその図解です。 


s sl 



図 4-5: String sl を指す &StHng s の図表 

注釈：&による参照の逆は、参照外しであり、参照外し演算子の*で達成できます。第8章で参 
照外し演算子の使用例を眺め、第15章で参照外しについて詳しく議論します。 

ここの関数呼び出しに ついて、 もっと詳しく見てみましょう： 

# fn calculate _ Length ^ s : & Stnng ) -> usize i 

# s . len () 

# } 

let sl = String : : from (" hello ") ; 
let len = calcuLate _ length (& sl ); 


この & S 1 という記法により、 sl の値を参照する参照を生成することができますが、これを所有する 
ことはありません。所有してないということは、指している値は、参照がスコープを抜けてもドロッ 
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プされないということです。 

同様に、関数のシグニチャでも、&を使用して引数 s の型が参照であることを示しています。説明 
的な注釈を加えてみましょう： 

fn calculate 一 ! _ength ( s : & String ) -> usize { // s は String への参照 
s.ien () 

} // ここで、 s はスコープ外になる。けど、参照しているものの所有権を持っているわけ 
ではないので 
//何も起こらない 

変数 S が有効なスコープは、あらゆる関数の引数のものと同じですが、所有権はないので、 S がス 
コープを抜けても、参照が指しているものをドロップすることはありません。関数が実際の値の代わ 
りに参照を引数に取ると、所有権をもらわないので、所有権を返す目的で値を返す必要はありません。 

関数の引数に参照を取ることを借用と呼びます。現実生活のように、誰かが何かを所有していたら、 
それを借りることができます。用が済んだら、返さなきゃいけないわけです。 

では、借用した何かを変更しようとしたら、どうなるのでしょうか？リスト 4-6 のコードを試し 
てください。ネタバレ注意：動きません！ 

フ アイ ル名： src / main.rs 

fn mann () { 

let s = String : : f rom (" hello ") ; 
change (& s ); 

} 


fn change(some_string: &String) { 
some_string.push_str(" , world") ; 

} 


リスト 4-6： 借用した値を変更しようと試みる 


これがエラーです： 

error[E0596] : cannot borrow immutable borrowed content '*some_string' as mutable 
(エラー： 不変な借用をした中身 '* some_string' を可変で借用できません） 

——> error.rs :8:5 


8 


fn change^some_stnng: &Stnng) { 

- use '&mut String 

some_string.push_str(", world"); 


cannot borrow as mutable 


here to make mutable 


変数が標準で不変なのと全く同様に、参照も不変なのです。参照している何かを変更することは叶 


わないわけです。 
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4.2.1 可変な参照 

一捻り加えるだけでリスト 4-6 のコードのエラーは解決します: 
フアイル名： src / main.rs 
fn mann() { 

let mut s = String: : f rom("hello") ; 
change(&mut s); 

} 


fn change(some_string: &mut String) { 
some_string.push_str(" , world") ; 

} 

始めに、 s を mut に変えなければなりませんでした。そして、 &mut s で可変な参照を生成し、 
some_stri ng: &mut String で可変な参照を受け入れなければなりませんでした。 

ところが、可変な参照には大きな制約が一つあります：特定のスコープで、ある特定のデータに対 
しては、一つしか可変な参照を持てないことです。こちらのコードは失敗します： 

フアイル名： src / main.rs 

Let mut s = Stn ng: : rrom("he Llo") ; 

let rl= &mut s; 
let r2 = &mut s; 


これがエラーです: 


error[E0499]: cannot borrow 's' as mutable more than once at a time 
(エラー： 一度に' s' を可変として 2 回以上借用することはできません） 

-- > borrow_twi.ee. r*s:5 :19 


4 


5 


6 


Let rl = &mut s; 

- first mutable borrow occurs here 
( 最初の可変な参照はここ） 
let r2 = &mut s; 

a second mutable borrow occurs here 

( 二つ目の可変な参照はここ） 

} 

- ti rst borrow ends here 

( 最初の借用はここで終わり） 


この制約は、可変化を許可するものの、それを非常に統制の取れた形で行えます。これは、新たな 
Rustacean にとっては、壁です。なぜなら、多くの言語では、いつでも好きな時に可変化できるから 
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です。 

この制約がある利点は、 コンパイ ラが コンパイル 時にデータ競合を防ぐことができる点です。デー 
夕競合とは、競合条件と類似していて、これら3つの振る舞いが起きる時に発生します： 

• 2つ以上のボインタが同じデータに同時にアクセスする。 

• 少なくとも 一つの ポインタが データに 書き込みを 行って いる。 

• データへのアクセスを同期する機構が使用されていない。 

データ競合は未定義の振る舞いを引き起こし、実行時に追いかけようとした時に特定し解決するの 
が難しい問題です。しかし、 Rust は、データ競合が起こるコードをコンパイルさえしないので、この 
問題が発生しないようにしてくれるわけです。 

いつものように、波かっこを使って新しいスコープを生成し、同時並行なものでなく、複数の可変 
な参照を作ることができます。 

let mut s = Stn ng : : rrom("he Llo ") ; 


{ 

let rl= &mut s; 

} // rl はここでスコープを抜けるので、問題なく新しい参照を作ることができる 

let r2 = &mut s; 


可変と不変な参照を組み合わせることに関しても、似たような規則が存在しています。この コード 
は エラーに なります： 

Let mut s = String: : rrom("he L lo ") ; 

let rl= & s ; // 問題なし 
let r2 = & s ; // 問題なし 
let r3 = &mut s ; // 大問題！ 


これがエラーです: 


error[E0502] : cannot borrow 's' as mutable because it is also borrowed as 
immutable 

(エラー： ' s ' は不変で借用されているので、可変で借用できません） 

-- > borrow_thri.ee. r*s: 6:19 


4 

5 

6 


let rl = &s; // no problem 

- immutable borrow occurs here 
let r2 = &s; // no problem 
let r3 = &mut s; // BIG PROBLEM 

a mutable borrow occurs here 


immutable borrow ends here 
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ふう！さらに不変な参照をしている間は、可変な参照をすることはできません。不変参照の使用者 
は、それ以降に値が突然変わることなんて予想してません！しかしながら、複数の不変参照をするこ 
とは可能です。データを読み込んでいるだけの人に、他人がデータを読み込むことに対して影響を与 
える能力はないからです。 

これらのエラーは、時としてイライラするものではありますが、 Rust コンパイラがバグの可能性を 
早期に指摘してくれ（それも実行時ではなくコンパイル時に)、問題の発生箇所をズバリ示してくれる 
のだと覚えておいてください。そうして想定通りにデータが変わらない理由を追いかける必要がなく 
なります。 

4.2.2 宙に浮いた参照 

ポインタのある言語では、誤ってダングリングポインタを生成してしまいやすいです。ダングリン 
グポインタとは、他人に渡されてしまった可能性のあるメモリを指すポインタのことであり、その箇 
所へのポインタを保持している間に、メモリを解放してしまうことで発生します。対照的に Rust で 
は、コンパイラが、参照がダングリング参照に絶対ならないよう保証してくれます：つまり、何らか 
のデータへの参照があったら、コンパイラは参照がスコープを抜けるまで、データがスコープを抜け 
ることがないよう確認してくれるわけです。 

ダングリング参照作りを試してみますが、コンパイラはこれをコンパイルエラーで阻止します： 

フアイル名： src / main.rs 
fn main () { 

let reference _ to_nothing = dangle (); 

} 

fn dangle () -> &Stri ng { 

let s = String : : f rom (" hello ") ; 


&s 


こちらがエラーです： 

error [ E 0106] : rrrissing lifetime specifier 
(エラー： ライフタイム指定子がありません） 

-- > main . rs :5:16 

I 

5 | fn dangle () -> &String { 

| A expected lifetime parameter 

I 

= help : this function's return type contains a borrowed value , but there is no 
value for it to be borrowed from 

( 助言：この関数の戻り値型は、借用した値を含んでいますが、借用される値がどこ 
にもありません） 

= nelp : consider giving it a 'static Lifetime 
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('static ライフタイムを与えることを考慮してみてください） 

このエラーメッセージは、まだ講義していない機能について触れています：ライフタイムです。ラ 
イフタイムについては第10章で詳しく議論しますが、ライフタイムに関する部分を無視すれば、こ 
のメッセージは、確かにこのコードが問題になる理由に関する鍵を握っています： 

this runction's return type contains a borrowed va Lue , but there is no va Lue 
for it to be borrowed from . 


dangle コードの各段階で一体何が起きているのかを詳しく見ていきましょう： 

フアイル名： src / main.rs 

fn dangle () -> &String { // dangle は String への參照を返す 
let s = String : : from (" hello ") ; // s は新しい String 
&s // String s への参照を返す 

} // ここで、 s はスコープを抜け、ドロップされる。そのメモリは消される。 
//危険だ 


s は、 dangle 内で生成されているので、 dangle のコードが終わったら、 s は解放されてしまいます 
が、そこへの参照を返そうとしました。つまり、この参照は無効な String を指していると思われる 
のです。よくないことです！コンパイラは、これを阻止してくれるのです。 

ここでの解決策は、 String を直接返すことです： 

fn no _ dangle () -> String { 

let s = String : : f rom (" hello ") ; 


} 

これは何の問題もなく動きます。所有権はムーブされ、何も解放されることはありません。 

4.2.3 参照の規則 

参照について議論したことを再確認しましょう： 

• 任意のタイミングで、一つの可変参照か不変な参照いくつでものどちらかを行える。 

• 参照は常に有効でなければならない。 

次は、違う種類の参照を見ていきましょう：スライスです。 
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4.3 スライス型 

所有権のない別のデータ型は、スライスです。スライスにより、コレクション全体というより、そ 
の内の一連の要素を参照することができます。 

ここに小さなプログラミング問題があります：文字列を受け取って、その文字列中の最初の単語を 
返す関数を書いてください。関数が文字列中に空白を見つけなかったら、文字列全体が一つの単語に 
違いないので、文字列全体が返されるべきです。 

この関数のシグニチヤについて考えてみましょう： 

fn ti rst_word(s : &Stnng) -> ? 

この関数、 first_word は引数に &String をとります。所有権はいらないので、これで十分です。で 
すが、何を返すべきでしょうか？文字列の一部について語る方法が全くありません。しかし、単語の 
終端の添え字を返すことができますね。リスト 4-7 に示したように、その方法を試してみましょう。 

フアイル名： src / main.rs 

fn ti rst_word (s : &Stn ng) -> usize { 
let bytes = s.as_bytes(); 


for (i ， &item) in bytes.iter().enumerate() { 
if item == b' ' { 
return i; 

} 

} 

s.len () 

} 

リスト 4-7: String 引数へのバイト数で表された添え字を返す fi rst_word 関数 

String の値を要素ごとに見て、空白かどうかを確かめる必要があるので、 as_bytes メソッドを使っ 
て、 String オブジェクトをバイト配列に変換しています。 

Let bytes = s.as_bytes(); 

次に、そのパイト配列に対して、 iter メソッドを使用してイテレータを生成しています： 
for い， tern) in bytes.iter() .enumerate() { 


イテレータについて詳しくは、第13章で議論します。今は、 iter は、コレクション内の各要素を 
返すメソッドであること、 enumerate が iter の結果を包んで、代わりにタプルの一部として各要素を 
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返すことを知っておいてください。 enumerate から返ってくるタプルの第 1 要素は、添え字であり、 
2番目の要素は、（コレクションの）要素への参照になります。これは、手動で添え字を計算するより 
も少しだけ便利です。 

enumerate メソッドがタプルを返すので、 Rust のあらゆる場所同様、パターンを使って、そのタプ 
ルを分配できます。従って、 for ループ内で、タプルの添え字に対する i とタプルの 1 バイトに対応 
する &item を含むパターンを指定しています。 • iter() .enumerate() から要素への参照を取得するの 
で、パターンに&を使っています。 

for ループ内で、バイトリテラル表記を使用して空白を表すバイトを検索しています。空白が見つ 
かったら、その位置を返します。それ以外の場合、 s.len() を使って文字列の長さを返します。 


it item == b' 
return i ; 


s.len() 


さて、文字列内の最初の単語の終端の添え字を見つけ出せるようになりましたが、問題がありま 
す。 usize 型を単独で返していますが、これは &String の文脈でのみ意味を持つ数値です。言い換え 
ると、 String から切り離された値なので、将来的にも有効である保証がないのです。リスト 4-7 の 
first_word 関数を使用するリスト 4-8 のプログラムを考えてください。 

フ アイ ル名： src / main.rs 

# fn ri rst_word (s : &Stn ng) -> usize { 

# let bytes = s.as_bytes(); 


# 

# 

# 

# 

# 


for (i ， &item) in bytes.iter().enumerate() { 
if item == b' ' { 
return i; 


# } 

# 

# s . len () 

# } 

# 

fn main () { 

let mut s = String : : from("hello worLd ") ; 

let word = fi rst_word (& s ); // word の中身は、値 5 になる 

s . clear (); // String を空にする。つまり、 nn と等しくする 


} 


// word はまだ値 5 を保持しているが、もうこの値を有効に使用できる文字列は存在し 
ない 0 

// word は完全に無効なのだ！ 



第 4 章所有権を理解する 


82 


リスト 4-8： fi rst _ word 関数の呼び出し結果を保持し 、 Stri ng の中身を変更する 

このプログラムは何の エラー もなく コンパイルが 通り、 word を s.clear() の呼び出し後に使用し 
ても、 コンパイルが 通ります。 word は s の状態に全く関連づけられていないので、その中身はまだ値 
5 のままです。その値 5 を変数 s に使用し、最初の単語を取り出そうとすることはできます が、 これ 
はバグでしょう。というのも、 s の中身は、 5 を word に保存してから変わってしまったからです。 

word 内の添え字が s に格納されたデータと同期されなくなるのを心配することは、面倒ですし間違 
いになりやすいです！これらの添え字を管理するのは、 second _ word 関数を書いたら、さらに脆くな 
ります。そのシグニチャは以下のようにならなければおかしいです： 

fn second_word(s : &Stnng) -> (usize ， usize) { 

今、私たちは開始と終端の添え字を追うようになりました。特定の状態のデータから計算されたけ 
ど、その状態に全く紐付かない値が増えました。同期を取る必要のある宙に浮いた関連性のない変数 
が3 つに なってしまいました。 

運の いいこと に、 Rust には この 問題への解決策が用意されています：文字列スライスです。 

4.3.1 文字列スライス 

文字列スライスとは、 String の一部への参照で、こんな見た目をしています： 

let s = String: : from("hello world") ; 

let hello = &s[0..5]; 
let world = &s[6..11]; 

これは、 String 全体への参照を取ることに似ていますが、余計な [0..5] という部分が付いていま 
す。 String 全体への参照というよりも、 String の一部への参照です。開始••終点という記法は、開始 
から始まり、終点未満までずっと続く範囲です。 

[sta rti ng_i ndex . . endi ng_i ndex ] と指定することで、角かっこに範囲を使い、スライスを生成で 
きます。ここで、 starting _ index はスライスの最初の位置、 ending _ index はスライスの終端位置よ 
りも、1大きくなります。内部的には、スライスデータ構造は、開始地点とスライスの長さを保持し 
ており、スライスの長さは endi ng_i ndex から starti ng_i ndex を引いたものに対応します。以上よ 
り 、 let world = &s [6..11] ;の場合には、 world は s の7バイト目へのポインタと5という長さを 
保持するスライスになるでしょう。 

図 4-6 は、これを図解しています。 
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図 4-6： Stri ng オブジェクトの一部を参照する文字列スライス 

Rust の..という範囲記法で、最初の蕃号（ゼロ）から始めたければ、2連ピリオドの前に値を書か 
なければいいのです。換言すれば、これらは等価です： 

let s = String : : f rom (" hello ") ; 

let slice = & s [0..2]; 
let slice = & s [..2]; 

同様の意味で、 String の最後のバイトをスライスが含むのならば、末尾の数値を書かなければいい 
のです。つまり、これらは等価になります： 

let s = String : : f rom (" hello ") ; 

Let len = s.len (); 

let slice = & s [3.. len ]; 
let slice = & s [3.; 

さらに、両方の値を省略すると、文字列全体のスライスを得られます。故に、これらは等価です： 
let s = String : : f rom (" hello ") ; 

Let len = s . len (); 
let slice = & s [0.. len ]; 
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let slice = & s [..] ; 

注釈：文字列スライスの範囲添え字は、有効な UTF -8 文字境界に置かなければなりません。マ 
ルチパイト文字の真ん中で文字列スライスを生成しようとしたら、エラーでプログラムは落 
ちるでしょう。文字列スライスを導入する目的で、この節では ASCII のみを想定しています; 
UTF -8 に関するより徹底した議論は、第8章の「文字列で UTF -8 エンコードされたテキスト 
を格納する」節で行います。 

これら全ての情報を心に留めて、 first ^ ord を書き直してスライスを返すようにしましょう。文字 
列スライスを意味する型は、 & str と記述します： 

フアイル名： src / main.rs 

fn first _ word ( s : & String ) -> &str { 
let bytes = s . as _ bytes (); 


for ( i ， & item ) in bytes . iter (). enumerate () { 
if item == b ' ' { 

return & s [0.. i ]; 

} 

} 

&s [..] 

} 

リスト 4-7 で取った手段と同じ方法で単語の終端添え字を取得しています。つまり、最初の空白を 
探すことです。空白を発見したら、文字列の最初と、空白の添え字を開始、終了地点として使用して 
文字列スライスを返しています。 

これで、 first _ word を呼び出すと、元のデータに紐付けられた単独の値を得られるようになりまし 
た。この値は、スライスの開始地点への参照とスライス中の要素数から構成されています。 

second _ word 関数についても、スライスを返すことでうまくいくでしよう： 

fn second _ word ( s : & String ) -> &str { 

これで、ずっと混乱しにくい素直な API になりました。なぜなら、 String への参照が有効なまま 
であることをコンパイラが、保証してくれるからです。最初の単語の終端添え字を得た時に、文字列 
を空っぽにして先ほどの添え字が無効になってしまったリスト 4-8 のプログラムのバグを覚えていま 
すか？そのコードは、論理的に正しくないのですが、即座にエラーにはなりませんでした。問題は後 
になってから発生し、それは空の文字列に対して、最初の単語の添え字を使用し続けようとした時で 
した。スライスならこんなバグはあり得ず、コードに問題があるなら、もっと迅速に判明します。ス 
ライスバージョンの first word を使用すると、コンパイルエラーが発生します： 
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フアイル名： src / mam.rs 
rn main () { 

let mut s = String: : from("heLlo worid ") ; 
let word = rirst _ word (& s ); 
s • clear (); // error ! ( エラー！） 

} 


こちらがコンパイルエラーです: 


error[E0502] : cannot borrow 's' as mutable because it is also borrowed as 
immutable 

(エラー： 不変として借用されているので、 ' s ' を可変で借用できません） 

——> src/mann.rs:6:5 


4 


6 


let word = first_word(&s パ 

- immutable borrow occurs here (不変借用はここで 


起きています） 


s. clear () ; // error ! ( エラー ！ ) 

八 mutable borrow occurs here (可変借用はここで起きています） 
immutable borrow ends here (不変借用はここで終わっています） 


借用規則から、何かへの不変な参照がある時、さらに可変な参照を得ることはできないことを思い 
出してください。 clear は String を切り詰める必要があるので、可変な参照を得ようとして失敗して 
いるわけです。 Rust のおかげで API が使いやすくなるだけでなく、ある種のエラー全てを完全にコ 
ンパイル時に排除してくれるのです！ 


4.3.1.1 文字列リテラルはスライスである 

文字列は、バイナリに埋め込まれると話したことを思い出してください。今やスライスのことを 
知ったので、文字列リテラルを正しく理解することができます。 

let s = "Hello, world ! " ; 

ここでの s の型は、 &str です：バイナリのその特定の位置を指すスライスです。これは、文字列が 
不変である理由にもなっています。要するに、 &str は不変な参照なのです。 


4.3.1.2 引数としての文字列スライス 

リテラルや String 値のスライスを得ることができると知ると、 first_word に対して、もう一つ改 
善点を見出すことができます。シグニチャです： 

fn first_word(s : &String) -> &str { 
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もっと経験を積んだ Rustacean なら、代わりにリスト 4-9 のようなシグニチヤを書くでしょう 0 
というのも、こうすると、同じ関数を String 値と & str ■値両方に使えるようになるからです。 

fn first _ word ( s : & str ) -> &str { 

リスト 4-9： s 引数の型に文字列スライスを使用して first _ word 関数を改善する 

もし、文字列スライスがあるなら、それを直接渡せます。 String があるなら、その String 全体の 
スライスを渡せます。 String への参照の代わりに文字列スライスを取るよう関数を定義すると、何も 
機能を失うことなく API をより一般的で有益なものにできるのです。 

Filename : src / mam.rs 

# fn first _ word ( s : & str ) -> &str { 

# let bytes = s . as _ bytes (); 

# 

# for ( i ， & item ) in bytes . iter (). enumerate () { 

# if item == b ' ' { 

# return & s [0.. i ]; 

# } 

# } 

# 

# &s[••] 

# } 

fn main () { 

let my_string = String : : from("hello world ") ; 

// fi rst_word は ' Stri ng ' のスライスに対して機能する 
let word = first _ word (& my _ string [..]); 

let my _ stnng _ literal= "hello world " ; 

// fi rst.word は文字列リテラルのスライスに対して機能する 

let word = first _ word (& my _ string _ literal [..]); 

// 文字列リテラルは、すでに文字列スライス * な * ので、 

// スライス記法なしでも機能するのだ！ 

let word = fi rst _ word ( mv _ stnng _ literal ); 

} 


4.3.2 他のスライス 

文字列リテラルは、ご想像通り、文字列に特化したものです。ですが、もっと一般的なスライス型 
も存在します。この配列を考えてください： 
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let a = [1, 2, 3, 4, 5] ; 

文字列の一部を参照したくなる可能性があるのと同様、配列の一部を参照したくなる可能性もあり 
ます。以下のようにすれば、参照することができます： 

let a = [1, 2, 3, 4, 5] ; 

let slice = & a [1..3]; 

このスライスは、& [ i 32] という型になります。これも文字列スライスと同じように動作します。つ 
まり、最初の要素への参照と長さを保持することです。他のすべての種類のコレクションに対して、 
この種のスライスは使用するでしょう。これらのコレクション について 詳しくは、第8章でベクタに 
ついて 話すときに議論します。 

4.4 まとめ 

所有権、借用、スライスの概念は、コンパイル時に Rust プログラムにおいて、メモリ安全性を保 
証します。 Rust 言語も他のシステムプログラミング言語と同じように、メモリの使用法について制御 
させてくれるわけですが、所有者が スコー プを抜けたときにデータの所有者に自動的にデータを片付 
けさせることは、この制御を得るために、余計なコードを書いてデバッグする必要がないことを意味 
します。 

所有権は、 Rust の他のいろんな部分が動作する方法に影響を与えるので、これ以降もこれらの概念 
についてさらに語っていく予定です。第5章に移って、 struct でデータをグループ化することについ 
て見ていきましょう。 
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構造体を使用して関係のあるデータを構 
造化する 


struct または、構造体は、意味のあるグループを形成する複数の関連した値をまとめ、名前付けで 
きる独自のデータ型です。あなたがオブジェクト指向言語に造詣が深いなら、 struct はオブジェクト 
のデータ属性みたいなものです。この章では、タプルと構造体を対照的に比較し、構造体の使用法を 
デモし、メソッドや関連関数を定義して、構造体のデータに紐付く振る舞いを指定する方法について 
議論します。構造体と enum (第6章で議論します）は、自分のプログラム領域で新しい型を定義し、 
Rust のコンパイル時型精査機能をフル活用する構成要素になります。 

5.1 構造体を定義し、インスタンス化する 

構造体は第 3 章で議論したタプルと似ています。タプル同様、構造体の一部を異なる型にできます。 
一方タブルとは違って、各データ片には名前をつけるので、値の意味が明確になります。この名前の 
おかげで、構造体はタプルに比して、より柔軟になるわけです：データの順番に頼って、インスタン 
スの値を指定したり、アクセスしたりする必要がないのです。 

構造体の定義は、 struct キーワードを入れ、構造体全体に名前を付けます。構造体名は、一つにグ 
ループ化されるデータ片の意義を表すものであるべきです。そして、波かっこ内に、データ片の名前 
と型を定義し、これはフィールドと呼ばれます。例えば、リスト 5-1 では、ユーザアカウントに関す 
る情報を保持する構造体を示しています。 

struct User i 

username : String , 
email : String , 
sign _ in _ count : u 64, 
active : bool , 

} 







第 5 章構造体を使用して関係のあるデータを構造化する_89 

リスト 5-1: User 構造体定義 

構造体を定義した後に使用するには、各フィールドに対して具体的な値を指定して構造体のインス 
タンスを生成します。インスタンスは、構造体名を記述し、 key : value ペアを含む波かっこを付け 
加えることで生成します。ここで、キーはフィールド名、値はそのフィールドに格納したいデータに 
なります。フィールドは、構造体で宣言した通りの順番に指定する必要はありません。換言すると、 
構造体定義とは、型に対する一般的な雛形のようなものであり、インスタンスは、その雛形を特定の 
データで埋め、その型の値を生成するわけです。例えば、リスト 5-2 で示されたように特定のユーザ 
を宣言することができます。 

# struct User { 

# username : String , 

# email : String , 

# sign _ in _ count : u 64, 

# active : bool , 

# } 

# 

let userl=User { 

email : String : : f rom (" someone @ example . com ") , 
username : String : : f rom (" someusernamel 23") , 
active : true , 
s " ign _ in _ count :1, 

}； 


リスト 5-2: User 構造体のインスタンスを生成する 


構造体から特定の値を得るには、ドット記法が使えます。このユーザの E メールアドレスだけが 
欲しいなら、この値を使いたかった場所全部で userl.email が使えます。インスタンスが可変であれ 
ば、ドット記法を使い特定のフィールドに代入することで値を変更できます。リスト 5-3 では、可変 
な User インスタンスの email フィールド値を変更する方法を示しています。 

# struct User { 

# username : String , 

# email : String , 

# sign _ in _ count : u 64, 

# active : bool , 

# } 

# 

let mut userl=User { 

email : String : : f rom (" someone @ example . com ") , 
username : String : : f rom (" someusernamel 23") , 
active : true , 
sign _ in _ count : 1, 

}； 


userl . email = String : : f rom (" anotheremail @ example . com ") ; 
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リスト 5-3 i ある User インスタンスの email フイールド値を変更する 

インスタンス全体が可変でなければならないことに注意してください； Rust では、一部のフィール 
ドのみを可変にすることはできないのです。また、あらゆる式同様、構造体の新規インスタンスを関 
数本体の最後の式として生成して、そのインスタンスを返すことを暗示できます。 

リスト 5-4 は、与えられた email と username で user インスタンスを生成する buiid _ user 関 
数を示しています。 active フィールドには true 値が入り、 sign _ in _ count には値1が入ります 0 

# struct User { 

# username : String , 

# email : String , 

# sign _ in _ count : u 64, 

# active : bool , 

# } 

# 

fn build _ user ( email : Stri ng , username : String ) -> User { 

User { 

email : email , 
username : username , 
active : true , 
sign _ in _ count :1, 



リスト 5-4： E メールとユーザ名を取り、 User インスタンスを返す build_user 関数 

構造体のフィールドと同じ名前を関数の引数にもつけることは筋が通っていますが、 email と 
username というフィールド名と変数を繰り返さなきゃいけないのは、ちょっと面倒です。構造体に 
もっとフィールドがあれば、名前を繰り返すことはさらに煩わしくなるでしょう。幸運なことに、便 
利な省略記法があります！ 

5.1.1 フィールドと変数が同名の時にフィールド初期化省略記法を使う 

仮引数名と構造体のフィールド名がリスト 5-4 では、全く一緒なので、フィールド初期化省略記 
法を使って build _ use 「 を書き換えても、振る舞いは全く同じにしつつ、リスト 5-5 に示したように 
emai 1と username を繰り返さなくてもよくなります。 


# struct User { 

# username : String , 

# email : String , 

# sign _ in _ count : u 64, 

# active : bool , 

# } 

# 

fn build _ user ( email : Stri ng , username : String ) -> User { 
User { 
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emaiL, 
username , 
active: true, 
sign_in_count : 1. 



リスト 5-5 ： email と username 引数が構造体のフィールドと同名なので、フィールド初期化省略法 
を使用する builcLuser •関数 

ここで、 email というフィールドを持つ User 構造体の新規インスタンスを生成しています 。 email 
フィールドを build_user 関数の email 引数の値にセットしたいわけです。 email フィールドと email 
引数は同じ名前なので、 email: email と書くのではなく、 email と書くだけで済むのです 0 

5 . 1.2 構造体更新記法で他のインスタンスからインスタンスを生成する 

多くは前のインスタンスの値を使用しつつ、変更する箇所もある形で新しいインスタンスを生成で 
きるとしばしば有用です。構造体更新記法でそうすることができます。 

まず、リスト 5-6 では、更新記法なしで user2 に新しい User インスタンスを生成する方法を示し 
ています。 email と username には新しい値をセットしていますが、それ以外にはリスト 5-2 で生成 
した userl の値を使用しています 0 

# struct User { 

# username : String, 

# email: String, 

# sign_in_count: u64, 

# active : bool, 

# } 

# 

# let userl=User { 

# email: String: : f rom("someone@example.com") , 

# username : String: : f rom("someusernamel23") , 

# active : true, 

# sign_in_count:1, 

# }； 

# 

let user2 = User { 

email: String: : f rom("another@example.com") , 
username : String: : f rom("anotherusername567 M ) , 
active : userl.active, 
sign_in_count : userl•sign_in_count, 

}； 


リスト 5-6 ： userl の一部の値を使用しつつ、新しい User インスタンスを生成する 


構造体更新記法を使用すると、リスト 5-7 に示したように、コード量を減らしつつ、同じ効果を達 
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成できます。..という記法により、明示的にセットされていない残りのフィールドが、与えられたイ 
ンスタンスのフィールドと同じ値になるように指定します。 

# struct User { 

# username : String , 

# email : String , 

# sign _ in _ count : u 64, 

# active : bool , 

# } 

# 

# let userl=User { 

# email : String : : f rom (" someone @ example . com ") , 

# username : String : : f rom (" someusernamel 23") , 

# active : true , 

# sign _ in _ count :1, 

# }; 

# 

let user 2 = User { 

email : String : : f rom (" another @ example . com ") , 
username : String : : f rom (" anotherusername 567") , 

•.userl 

}； 


リスト 5-7: 構造体更新記法を使用して、新しい User インスタンス用の値に新しい email と 
username をセットしつつ、残りの値は、 userl 変数のフィールド値を使う 

リスト 5-7 のコードも、 email と username については異なる値、 active と sign_in_count フィー 
ルドについては、 userl と同じ値になるインスタンスを user2 に生成します。 

5.1.3 異なる型を生成する名前付きフィールドのないタプル構造体を使用する 

構造体名により追加の意味を含むものの、フィールドに紐づけられた名前がなく、むしろフィール 
ドの型だけのタプル構造体と呼ばれる、タプルに似た構造体を定義することもできます。タプル構造 
体は、構造体名が提供する追加の意味は含むものの、フィールドに紐付けられた名前はありません；む 
しろ、フィールドの型だけが存在します。タプル構造体は、タプル全体に名前をつけ、そのタブルを 
他のタブルとは異なる型にしたい場合に有用ですが、普通の構造体のように各フィールド名を与える 
のは、冗長、または余計になるでしょう。 

タプル構造体を定義するには、 struct キーワードの後に構造体名、さらにタプルに含まれる型を続 
けます。例えば、こちらは、 Color と Point という 2 種類のタプル構造体の定義と使用法です： 

struct Color* い .32, i32, i32) ; 
struct Point (i 32 , "i32 , "i32) ; 

let black = Color (0, 0, 0); 
let origin = Point(0, 0, 0); 
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black と origin の値は、違う型であることに注目してください。これらは、異なるタプル構造体の 
インスタンスだからですね。定義された各構造体は、構造体内のフィールドが同じ型であっても、そ 
れ自身が独自の型になります。例えば、 Color 型を引数に取る関数は、 Point を引数に取ることはで 
きません。たとえ、両者の型が、3 つの i32 値からで きていて もです。それ以外に ついては、 タプル 
構造体のインスタンスは、タプルと同じように振る舞います：分配して個々の部品にしたり、.と添え 
字を使用して個々の値にアクセスするなどです。 

5.1.4 フィー ルドのない ユニッ ト様（よう）構造体 

また、一切フィールドのない構造体を定義することもできます！これらは、（）、 ユニット 型と似 
たような振る舞いをすることから、ユニット様構造体と呼ばれます。 ユニット 様構造体は、ある型に 
トレイトを実装するけれども、型自体に保持させるデータは一切ない場面に有効になります。トレイ 
卜について は第10章で議論します。 


5.1.5 構造体データの所有権 

リスト 5-1 の User 構造体定義において、 &str 文字列 スライス 型ではなく、所有権のある 
String 型を使用しました。これは意図的な選択です。というのも、 この 構造体の インスタンス 
には全データを所有してもらう必要があり、 この データは、構造体全体が有効な間はずっと有 
効である必要があるのです。 

構造体に、他の何かに所有されたデータへの参照を保持させることもできますが、そうするに 
はライフタイムという第10章で議論する Rust の機能を使用しなければなりません。ライフ 
タイムのおかげで構造体に参照されたデータが、構造体自体が有効な間、ずっと有効であるこ 
とを保証してくれるのです。ライフタイムを指定せずに構造体に参照を保持させようとしたと 
しましょう。以下の通りですが、これは動きません： 

フ アイ ル名： src / main.rs 

struct User i 

username: &str , 
email: &str , 
sign_in_count: u64, 
active: bool , 

} 

fn main() { 

let userl=User { 

email: "someone@example.com", 
username: M someusernamel23" , 
active: true, 
sign_in_count : 1, 


}； 



第 5 章構造体を使用して関係のあるデータを構造化する 


94 


} 


コンパイラは、ライフタイム指定子が必要だと怒るでしょう： 

error [ E 0106] : missing lifetime specifier 
( エラー： ライフタイム指定子がありません） 

—— > 

I 

2 | username : & str , 

| A expected lifetime parameter 

( ライフタイム引数を予期しました） 

error [ E 0106] : missing lifetime specifier 
—— > 

I 

3 | email :& str , 

| A expected lifetime parameter 

第 io 章で、これらのエラーを解消して構造体に参照を保持する方法に ついて 議論しますが、 
当面、今回のようなエラーは、 &str のような参照の代わりに、 String のような所有された型 
を使うことで修正します。 


5.2 構造体を使ったプログラム例 

構造体を使用したくなる可能性のあるケースを理解するために、四角形の面積を求めるプログラム 
を書きましょう。単一の変数から始め、代わりに構造体を使うようにプログラムをリファクタリング 
します。 

Cargo で rectangles という新規バイナリプロジェクトを作成しましょう。このプロジェクト 
は、四角形の幅と高さをピクセルで指定し、その面積を求めます。リスト 5-8 に、プロジェクトの 
src / main . rs で、正にそうする一例を短いプログラムとして示しました。 

フアイル名： src/main.rs 

fn mann () { 

let widthl = 30; 
let heightl = 50; 


println ! ( 

// 四角形の面積は、 {} 平方ピクセルです 

"The area of the rectangle is {} square pixels .", 
area ( widthl , heightl ) 

)； 

} 


fn area ( width : u 32, height : u 32) -> u 32 { 
width ★ height 
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} 

リスト 5-8: 個別の幅と高さ変数を指定して四角形の面積を求める 

では、 cargo run でこのプログラムを走らせてください： 

The area of the rectangle is 1500 square pixels. 

( 四角形の面積は、 1500 平方ピクセルです） 

5.2.1 タプルでリファクタリングする 

リスト 5-8 のコードはうまく動き、各次元で area 関数を呼び出すことで四角形の面積を割り出し 
ますが、改善点があります。幅と高さは、組み合わせると一つの四角形を表すので、相互に関係があ 
るわけです。 

このコードの 問題点は、 a rea のシ グニチャから明らかです： 
fn area(width : u32, height: u32) -> u32 { 

area 関数は、 1 四角形の面積を求めるものと考えられますが、今書いた関数には、弓 I 数が 2 つあり 
ます。引数は関連性があるのに、このプログラム内のどこにもそのことは表現されていません。幅と 
高さを一緒にグループ化する方が、より読みやすく、扱いやすくなるでしょう。それをする 一つの 方 
法については、第3章の「タプル型」節ですでに議論しました：タプルを使うのです。 

5.2.2 タプルでリファクタリングする 


リスト 5-9 は、タプルを使う別バージョンのプログラムを示しています。 


フアイル名： src/mam.rs 

rn main() { 

let recti=(30 ， 50); 


println! ( 

"The area of the rectangle is {} square pixels. 11 , 
area(recti) 

)； 

} 

fn area(dimensions: (u32 , u32) ) -> u32 { 
dimensions.0 * dimensions.1 

} 


リスト 5-9: タプルで四角形の幅と高さを指定する 
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ある意味では、このプログラムはマシです。タプルのおかげで少し構造的になり、一引数を渡すだ 
けになりました。しかし別の意味では、このバージョンは明確性を失っています：タプルは要素に名 
前を付けないので、計算が不明瞭になったのです。なぜなら、タプルの一部に添え字アクセスする必 
要があるからです。 

面積計算で幅と高さを混在させるのなら問題はないのですが、四角形を画面に描画したいとなると、 
問題になるのです！タプルの添え字0が幅で、添え字1が高さであることを肝に銘じておかなけれ 
ばなりません。他人がこのコードをいじることになったら、このことを割り出し、同様に肝に銘じな 
ければならないでしょう。容易く、このことを忘れたり、これらの値を混ぜこぜにしたりしてエラー 
を発生させてしまうでしょう。データの意味をコードに載せていないからです。 

5.2.3 構造体でリファクタリングする：より意味付けする 

データにラベル付けをして意味付けを行い、構造体を使います。現在使用しているタプルを全体と 
一部に名前のあるデータ型に、変形することができます。そう、リスト 5-10 に示したように。 

フアイル名： src / main.rs 


struct Rectangle { 
width : u 32 , 
height : u 32 , 

} 

fn main () { 

let recti=Rectangle { width : 30, height : 50 }; 
println ! ( 

"The area of the rectangle is {} square pixels . 11 , 
area (& rectl ) 

)； 

} 

fn area ( rectangle : & Rectangle ) -> u 32 { 
rectangle.width ★ rectangle•height 

} 

リスト 5-10； Rectangle 構造体を定義する 

ここでは、構造体を定義し、 Rectangle という名前にしています。波括弧の中で width と height と 
いうフィールドを定義し、 u 32 という型にしました。それから main 内で Rectangle の特定のインス 
タンスを生成し、幅を30、高さを50にしました。 

これで area 関数は引数が一つになり、この引数は名前が rectangle 、型は Rectangle 構造体イン 
スタンスへの 不変借用になりました。第4章で触れたように、構造体の所有権を奪うよりも借用する 
必要があります。こうすることで main は所有権を保って、 recti を使用し続けることができ、そのた 
めに関数 シグ ニチャと関数呼び出し時に&を使っているわけです。 
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area 関数は、 Rectangle インスタンスの width と height フィールドにアクセスしています。これ 
で、 area の関数シグニチャは、我々の意図をズバリ示すようになりました： width と height フィール 
ドを使って、 Rectangle の面積を計算します。これにより、幅と高さが相互に関係していることが伝 
わり、タプルの0や1という添え字を使うのではなく、値に説明的な名前を与えられるのです。簡潔 
性を勝ち取ったわけですね。 

5.2.4 トレイトの継承で有用な機能を追加する 

プログラムのデバッグをしている間に、 Rectangle のインスタンスを出力し、フィールドの値を確 
認できると、素晴らしいわけです。リスト 5-11 では、以前の章のように、 println ! マクロを試しに 
使用しようとしていますが、動きません。 

ファイル名： src / main.rs 


struct Rectangle { 
width : u 32, 
height : u 32 , 

} 

fn mai . n () { 

let recti=Rectangle { width : 30, height : 50 }; 

// recti は {} です 

println! ( "recti is {}" , recti ); 

} 

リスト 5-11: Rectangle のインスタンスを出力しようとする 

このコードを走らせると、こんな感じのエラーが出ます： 

error [ E 0277] : the trait bound Rectangle : std :: fmt :: DispLay is not satisfied 

( エラー： トレイト境界' Rectangle : std : : fmt : : Display ' が満たされていません） 

println ! マクロには、様々な整形があり、標準では、波括弧は Display として知られる整形をす 
るよう、 println ! に指示するのです：直接エンドユーザ向けの出力です。これまでに見てきた基本型 
は、標準で Display を実装しています。というのも、1や他の基本型をユーザに見せる方法は一つし 
かないからです。しかし構造体では、 println ! が出力を整形する方法は自明ではなくなります。出力 
方法がいくつもあるからです：カンマは必要なの？波かっこを出力する必要はある？全フィールド 
が見えるべき？この曖昧性のため、 RllSt は必要なものを推測しようとせず、構造体には Display 実 
装が提供されないのです。 

エラーを読み下すと、こんな有益な注意書きがあります： 


Rectangle cannot be formatted with the default formatter ; trv using 
:?' instead if you are using a format string 
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(注釈：' Rectangle' は、デフォルト整形機では、整形できません；フォーマット文字列を 
使うのなら 

代わりに':?'を試してみてください） 

試してみましょう！ pritnln !マクロ呼び出しは、 println! ("recti is {:?}", recti); という見 
た目になるでしょう。波括弧内に：？という指定子を書くと、 println! に Debug と呼ばれる出力整形 
を使いたいと指示するのです。 Debug トレイトは、開発者にとって有用な方法で構造体を出力させて 
くれるので、コードをデバッグしている最中に、値を確認することができます。 

変更してコードを走らせてください。なに！まだエラーが出ます： 

error[E0277] : the trait bound Rectangle : std : :rmt::Debug is not satisfied 
( エラー： トレイト境界' Rectangle : std : : fmt : : Debug' は満たされていません） 

しかし今回も、コンパイラは有益な注意書きを残してくれています： 

Rectangle cannot be formatted using : r;if it is denned in vour 
crate, add '#[derive(Debug)]' or manually implement it 

(注釈： 'Rectangle' は':?'を使って整形できません；自分のクレートで定義しているのな 
ら 

'#[deHve(Debug)]' を追加するか、手動で実装してください） 

確かに Rust にはデバッグ用の情報を出力する機能が備わっていますが、この機能を構造体で使え 
るようにするには、明示的な選択をしなければならないのです。そうするには、構造体定義の直前に 
#[derive(Debug)] という注釈を追加します。そう、リスト 5-12 で示されている通りです。 

フアイル 名： src / main.rs 

# [derive(Debug)] 
struct Rectangle { 
width: u32, 
height: u32 , 

} 

fn main() { 

let recti=Rectangle { width: 30, height: 50 }; 
println! ("recti is {:?}", recti); 

} 

リスト 5-12： Debug トレイトを継承する注釈を追加し、 Rectangle インスタンスをデバッグ用整形 
機で出力する 

これでプログラムを実行すれば、エラーは出ず、以下のような出力が得られるでしょう： 

recti is Rectangle i width: 30 ， height: 50 } 


素晴らしい！最善の出力では ないものの、このインスタンスの 全 フィールドの 値を出力して いるの 
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で、デバッグ中には間違いなく役に立つでしょう。より大きな構造体があるなら、もう少し読みやす 
い出力の方が有用です；そのような場合には、 println! 文字列中の {:?} の代わりに {:#?} を使うこと 
ができます。この例で {:#?} というスタイルを使用したら、出力は以下のようになるでしょう： 

recti is Rectangle i 
width: 30, 
height: 50 

} 

Rust には、 derive 注釈で使えるトレイトが多く提供されており、独自の型に有用な振る舞いを追 
加することができます。そのようなトレイトとその振る舞いは、付録 C で一覧になっています。これ 
らのトレイトを独自の動作とともに実装する方法だけでなく、独自のトレイトを生成する方法につい 
ては、第10章で解説します。 

area 関数は、非常に特殊です：四角形の面積を算出するだけです。 Rectangle 構造体とこの動作を 
より緊密に結び付けられると、役に立つでしょう。なぜなら、他のどんな型でもうまく動作しなくな 
るからです。 area 関数を Rectangle 型に定義された area メソッ ドに変形することで、この コー ドを 
リファクタリングし続けられる方法について見ていきましょう。 

5.3 メソッド記法 

メソッドは関数に似ています： fn キーワードと名前で宣言されるし、引数と返り値があるし、どこ 
か別の場所で呼び出された時に実行されるコードを含みます。ところが、メソッドは構造体の文脈（あ 
るいは enum かトレイトオブジェクトの。これらについては各々第6章と17章で解説します）で定 
義されるという点で、関数とは異なり、最初の引数は必ず self になり、これはメソッドが呼び出さ 
れている構造体インスタンスを表します。 

5.3.1 メソッドを定義する 

Rectangle インスタンスを 引数に取る area 関数を変え、代わりに Rectangle 構造体上に area メ 
ソッドを作りましょう。リスト 5-13 に示した通りですね。 

フアイル名： src / main.rs 

# [derive(Debug)] 
struct Rectangle { 
width: u32 , 
height: u32 , 

} 

impl Rectangle { 

fn area(&self) -> u32 { 

self. width ^ self .height 

} 
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} 

fn mann() { 

let recti=Rectangle { width: 30 ， height: 50 }; 
println! ( 

"The area of the rectangle is {} square pixels." , 
recti.area() 

)； 

> 


リスト 5-13: Rectangle 構造体上に area メソッドを定義する 

Rectangle の文脈内で関数を定義するには、 impt ( implementation ; 実装）ブロックを始めます。 
それから area 関数を impl の波かっこ内に移動させ、最初の（今回は唯一の）引数をシグニチヤ内と 
本体内全てで self に変えます 0 area 関数を呼び出し、 recti を引数として渡す main では、代替とし 
てメソッド記法を使用して、 Rectangle インスタンスの area メソッドを呼び出せます。メソッド記法 
は、 インスタンスの 後に続きます：ドット、メソッド名、かっこ、そして引数と続くわけです。 

area のシグニチヤでは、 rectangle : &Rectangle の代わりに &self を使用しています。というの 
も、 コンパイ ラは、このメソッドが impl Rectangle という文脈内に存在するために、 self の型が 
Rectangle であると把握しているからです。 &Rectangle と同様に、 self の直前に&を使用しているこ 
とに注意してください。メソッドは、 self の所有権を奪ったり、ここでしているように不変で self 
を借用したり、可変で self を借用したりできるのです。他の引数と全く同じですね。 

ここで &self を選んでいるのは、関数バージヨンで &Rectangle を使用していたのと同様の理由で 
す：所有権はいらず、構造体のデータを読み込みたいだけで、書き込む必要はないわけです。メソッ 
ドの一部でメソッドを呼び出したインスタンスを変更したかったら、第 1 引数に &mut self を使用す 
るでしょう。 self だけを第 1 引数にしてインスタンスの所有権を奪うメソッドを定義することは稀で 
す；このテクニックは通常、メソッドが self を何か別のものに変形し、変形後に呼び出し元が元のイ 
ンスタンスを使用できないようにしたい場合に使用されます。 

関数の代替としてメソッドを使う主な利点は、メソッド記法を使用して全メソッドのシグニチヤで 
self の型を繰り返す必要がなくなる以外だと、体系化です。コードの将来的な利用者に Rectangle の 
機能を提供しているライブラリ内の各所でその機能を探させるのではなく、この型のイ ンスタンスで 
できることを 一つの impl ブロックにまとめあげています。 

5.3.2 -> 演算子はどこに行ったの？ 

C と C ++ では、メソッド呼び出しには2種類の異なる演算子が使用されます：オブジェクトに 
対して直接メソッドを呼び出すのなら、•を使用するし、オブジェクトのポインタに対してメ 
ソッドを呼び出し、先にポインタを参照外しする必要があるなら、 -> を使用するわけです。言 
い 換えると、 object がポインタなら、 object->something() は、 （ *obiect) • somethi ng() と同 



第 5 章構造体を使用して関係のあるデータを構造化する 


101 


等なのです。 

Rust には -> 演算子の代わりとなるようなものはありません；その代わり、 Rust には、自動参 
照および参照外しという機能があります。 Rust においてメソッド呼び出しは、この動作が行わ 
れる数少ない箇所なのです。 

動作方法はこうです： ob j ect. somethi ng () とメソッドを呼び出すと、コンパイラは object が 
メソッドのシグニチャと合致するように、自動で & か &mut 、 * を付与するのです。要するに、 
以下のコードは同じものです： 

# [derive(Debua,Copy, c Lone)] 

# struct Point { 

# x: f64, 

# y: f64, 

# } 

# 

# impl Point { 

# fn distance (&self, other: &Point) -> f64 { 

# let x_squared = f64 :: powi(other.x - self .x, 2); 

# let y_squared = f64 :: powi(other.y - self .y, 2); 

# 

# f64: : sqrt(x_squared + y_squared) 

# } 

# } 

# let pi=Point { x: 0.0, y : 0.0 }; 

# let p2 = Point { x: 5.0, y : 6.5 }; 
pi.distance(&p2); 

(&pl).distance(&p2); 

前者の方がずっと明確です。メソッドには自明な受け手 （ self の型）がいるので、この自動参 
照機能は動作するのです。受け手とメソッド名が与えられれば、コンパイラは確実にメソッド 
が読み込み専用 （ &self) か、書き込みもする （&mut self) のか、所有権を奪う （self ) のか判 
断できるわけです。 Rust において、メソッドの受け手に関して借用が明示されないという事実 
は、所有権を現実世界でエルゴノミックにさせる大部分を占めているのです。 

5.3.3 より引数の多いメソッド 

Rectangle 構造体に2番目のメソッドを実装して、メソッドを使う鍛錬をしましょう。今回は、 
Rectangle のインスタンスに、別の Rectangle のインスタンスを取らせ、2香目の Rectangle が self 
に完全にはめ込まれたら、 true を返すようにしたいのです；そうでなければ、 false を返すべきです。 
つまり、一旦 cam_hold メソッドを定義したら、リスト 5-14 のようなプログラムを書けるようになり 
たいのです。 

フアイル名： src/main.rs 


fn main() i 
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let recti = Rectangle { width: 30 ， height: 50 }; 
let rect2 = Rectangle { width:10, height: 40 }; 
let rect3 = Rectangle { width: 60, height: 45 }; 


// recti に rect2 ははまり込む？ 

println! ("Can recti hold rect2? {}" , recti•can 一 hold(&rect2)); 
println! ("Can recti hold rect3? {}"， recti•can 一 hold(&rect3)); 


リスト 5-14: 未完成の can_hold を使用する 

そして、予期される出力は以下のようになります。なぜなら、 r*ect2 の各次元は recti よりも小さ 
いものの、 rect3 は recti より幅が広いからです： 


Can recti hold rect2? true 
Can recti hold rect3? false 


メソッドを定義したいことはわかっているので 、 impl Rectangle ブロック内での話になります。メ 
ソッド名は、 can_h 01 d になり、引数として別の Rectangle を不変借用で取るでしょう。メソッドを 
呼び出すコードを見れば、引数の型が何になるかわかります： rectl.can_h 01 d(&rect2) は、 &rect2 、 
Rectangle のインスタンスである rect2 への不変借用を渡しています。これは道理が通っています 0 
なぜなら、 rect2 を読み込む（書き込みではなく。この場合、可変借用が必要になります）だけでよぐ 
Can _hold メソッドを呼び出した後にも r*ect2 が使えるよう、所有権を main に残したままにしたいか 
らです。 can_h 01 d の返り値は、 boolean になり、メソッドの中身は、 self の幅と高さがもう一つの 
Rectangle の幅と高さよりも、それぞれ大きいことを確認します。リスト 5-13 の impl ブロックに新 
しい can_hold メソッドを追記しましょう。リスト 5-15 に示した通りです。 

フアイル名： src/main.rs 

# # [derive(Debug)] 

# struct Rectangle i 

# width : u32 , 

# height: u32 , 

# } 

# 

impl Rectangle { 

fn area(&self) -> u32 { 

self. width ^ self .height 

} 

fn can_hold (&self , other: &Rectangle) -> bool { 

self .width > other.width && self .height > other.height 

} 

} 


リスト 5-15: 別の Rectangle のインスタンスを引数として取る can_hold メソッドを 、 Rectangle 
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に実装する 

このコードをリスト 5-14 の main 関数と合わせて実行すると、望み通りの出力が得られます。メ 
ソッドは、 self 引数の後にシグニチャに追加した引数を複数取ることができ、その引数は、関数の引 
数と同様に動作するのです。 

5.3.4 関連関数 

impt ブロックの別の有益な機能は、 impl ブロック内に self を引数に取らない関数を定義できるこ 
とです。これは、構造体に関連付けられているので、関連関数と呼ばれます。それでも、関連関数は 
関数であり、メソッドではありません。というのも、対象となる構造体のインスタンスが存在しない 
からです。もう String :: 什 om という関連関数を使用したことがありますね。 

関連関数は、構造体の新規インスタンスを返すコンストラクタによく使用されます。例えば、一次 
元の引数を取り、長さと幅両方に使用する関連関数を提供することができ、その結果、同じ値を2回 
指定する必要なく、正方形の Rectangle を生成しやすくすることができます。 

フ アイ ル名： src/main.rs 


# # [derive(Debug)] 

# struct Rectangle { 

# width: u32, 

# height : u32 , 

# } 

# 

impl Rectangle { 

fn square(size: u32) -> Rectangle { 

Rectangle { width: size, height: size } 



この関連関数を呼び出すために、構造体名と一緒に：：記法を使用します；一例は let sq = 
Rectangle: :square(3) ;です。この関数は、構造体によって名前空間分けされています：：：という記 
法は、関連関数とモジュールによって作り出される名前空間両方に使用されます。モジュールについ 
ては第7章で議論します。 

5.3.5 複数の Impl ブロック 

各構造体には、複数の impl ブロックを存在させることができます。例えば、リスト 5-15 はリス 
卜 5-16 に示したコードと等価で、リスト 5-16 では、各メソッドごとに impl ブロックを用意してい 
ます。 


# # [derive(Debug)] 

# struct Rectangle { 
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# width : u32 , 

# height: u32, 

# } 

林 

imp l Rectangle { 

fn area(&self) -> u32 { 

self. width ^ self .height 



impl Rectangle { 

fn can_hold (&self , other: &Rectangle) -> bool { 

self .width > other.width && self .height > other.height 



リスト 5-16: 複数の impl ブロックを使用してリスト 5-15 を書き直す 

ここでこれらのメソッドを個々の impl ブロックに分ける理由はないのですが、合法な書き方です。 
複数の impl ブロックが有用になるケースは第 10 章で見ますが、そこではジェネリック型と、トレイ 
卜 について 議論します。 

5.4 まとめ 

構造体により、自分の領域で意味のある独自の型を作成することができます。構造体を使用するこ 
とで、関連のあるデータ片を相互に結合させたままにし、各部品に名前を付け、コードを明確にする 
ことができます。メソッドにより、構造体のインスタンスが行う動作を指定することができ、関連関 
数により、構造体に特有の機能をインスタンスを利用することなく、名前空間分けすることができ 
ます。 

しかし、構造体だけが独自の型を作成する手段ではありません： Rust の enum 機能に目を向けて、 
別の道具を道具箱に追加しましょう。 



105 



6 


Enum とパターンマッチング 


この 章では、列挙型について見ていきます。列挙型は、 enum とも称されます。 enum は、取りう 
る値を列挙することで、型を定義させてくれます。最初に、 enum を定義し、使用して、 enum が 
データとともに意味をコード化する方法を示します。次に、特別に有用な enum である option につ 
いて掘り下げていきましょう。 この 型は、値が何かかなんでもないかを表現します。それから、 match 
式のパターンマッチングにより、どう enum の色々な値に対して異なるコードを走らせやすくなる 
かを見ます。最後に、 if let 文法要素も、如何（いか）に enum をコードで扱う際に使用可能な便利 
で簡潔な慣用句であるかを解説します。 

enum は多くの言語に存在する機能ですが、その能力は言語ごとに異なります。 Rust の enum 
は、 F #、 OCaml 、 Haskell などの、関数型言語に存在する代数的データ型に最も酷似しています。 

6.1 Enum を定 tel " る 

コードで表現したくなるかもしれない場面に目を向けて、 enum が有用でこの場合、構造体よりも 
適切である理由を確認しましょう 。 IP アドレスを 扱う必要が出たとしましょう。現在 、 IP アドレスの 
規格は二つあります：バージョン4とバージョン6です。これらは、プログラムが遭遇する IP アドレ 
スのすべての 可能性です：列挙型は、取りうる値を すべて 列挙でき、これが列挙型の名前の由来です。 

どんな IP アドレスも、バージョン4かバージョン6のどちらかになりますが、同時に両方にはな 
り得ません。 IP アドレスのその特性により、 enum データ構造が適切なものになります。というの 
も、 enum の値は、その列挙子のいずれか一つにしかなり得ないからです。バージョン4とバージョ 
ン6のアドレスは、どちらも根源的には IP アドレスですから、コードがいかなる種類の IP アドレス 
にも適用される場面を扱う際には、同じ型として扱われるべきです。 

この概念をコードでは、 IpAddrKind 列挙型を定義し、 IP アドレスがなりうる種類、 V4 と V6 を列 
挙することで、表現できます。これらは、 enum の列挙子として知られています： 


enum IpAddrKind i. 
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V4 ， 

V6 ， 

} 

これで、 IpAddrKind はコードの他の場所で使用できる独自のデータ型になります。 

6.1.1 Enum の値 

以下のようにして、 IpAddrKind の各列挙子のインスタンスは生成できます： 


# enum IpAddrKind { 

# V4, 

# V6, 

# } 

# 

let four = IpAddrKind :: V4; 
let six = IpAddrKind :: V6; 


enum の列挙子は、その識別子の元に名前空間分けされていることと、 2 連 コロンを 使ってその二つ 
を区別していることに注意してください。これが有効な理由は、こうすることで、値 IpAddrKind: :V4 
と IpAddrKind::V6 という値は両方とも、同じ型 IpAddrKind になったからです。そうしたら、例え 
ば、どんな IpAddrKind を 取る関数も定義できるようになります。 


# enum IpAddrKind { 

# V4, 

# V6, 

# } 

林 

fn routenp_type: IpAdarKind)i j- 


そして、この関数をどちらの列挙子に対しても呼び出せます : 


# enum IpAddrKind { 

# V4, 

# V6, 

# } 

# 

# fn route(ip_type: IpAddrKind) { } 

# 

route(IpAddrKind :: V4); 
route(IpAddrKind :: V6); 

enum の利用には、さらなる利点さえもあります。この IP アドレス型についてもっと考えてみる 
と、現状では、実際の IP アドレスのデータを保持する方法がありません。つまり、どんな種類である 
かを知っているだけです。構造体について第 5 章で学んだばっかりとすると、この問題に対して、あ 
なたはリスト 6-1 のように対処するかもしれません。 
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enum IpAddrKind i 
V4, 

V6, 


struct IpAddr { 

kind: IpAddrKind, 
address : String, 

} 

let home = IpAddr { 

kind: IpAddrKind :: V4, 

address : String: : from("127.0.0.1 M ) , 

}； 

let loopback = IpAddr { 
kind: IpAddrKind :: V6, 
address : String: :from( n :: l n ) ， 

}； 


リスト 6-1: IP アドレスのデータと IpAddrKind の列挙子を struct を使って保持する 

ここでは、二つのフィールドを持つ IpAddr という構造体を定義しています： IpAddrKind 型（先ほど 
定義した Gnurn ですね）の ki nd フィールドと、 Stri ng 型の address フィールドです。この構造体の 
インスタンスが2つあります。最初のインスタンス、 home には kind として IpAddrKind : :V4 があり、 
紐付けられたアドレスデータは 127.0.0.1 です。2番目のインスタンス、 100 pback には、 kind の値 
として、 IpAddrKind のもう一つの列挙子、 V6 があり、アドレス：： 1 が紐付いています。構造体を使っ 
て kind と address 値を一緒に包んだので、もう列挙子は値と紐付けられています。 

各 enum の列挙子に直接データを格納して、 enum を構造体内に使うというよりも enum だけを 
使って、同じ概念をもっと簡潔な方法で表現することができます。この新しい IpAddr の定義は、 V4 
と V6 列挙子両方に String 値が紐付けられていることを述べています。 


enum IpAddr i 
V4 (String), 

V6(String) , 

} 

let home = IpAddr: : V4(String: : f rom("127 .0.0. 1") ); 
let loopback = IpAddr: : V6(String: : from(" : :1 M )) ; 

enum の各列挙子にデータを直接添付できるので、余計な構造体を作る必要は全くありません。 
構造体よりも enum を使うことには、別の利点もあります：各列挙子に紐付けるデータの型と量 
は、異なってもいいのです。バージョン4の IP アドレスには、常に0から255の値を持つ4つの数 
値があります。 V 4 のアドレスは、4つの U 8 型の値として格納するけれども、 V 6 のアドレスは引き続 
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き、単独の string 型の値で格納したかったとしても、構造体では不可能です。 enum なら、こんな 
場合も容易に対応できます： 


enum IpAddr i 

V4(u8, u8 , u8 , u8) , 

V6(String) , 

} 

let home = IpAddr: : V4(127, 0 ， 0 ， 1); 

let loopback = IpAddr: : V6(String: : from(" : :1")) ; 

バージョン 4 とバージョン 6 の IP アドレスを格納するデータ構造を定義する複数の異なる方法を 
示してきました。しかしながら、蓋を開けてみれば、 IP アドレスを格納してその種類をコード化した 
くなるということは一般的なので、標準ライブラリに使用可能な定義があります！標準ライブラリで 
の IpAddr の定義のされ方を見てみましょう：私たちが定義し、使用したのと全く同じ enum と列挙 
子がありますが、アドレスデータを二種の異なる構造体の形で列挙子に埋め込み、この構造体は各列 
挙子用に異なる形で定義されています。 

struct Ipv4Addr { 

//省略 

} 

struct Ipv6Addr { 

//省略 

} 

enum IpAddr i 

V4(Ipv4Addr) , 

V6(Ipv6Addr) , 

} 

このコードは、 enum 列挙子内にいかなる種類のデータでも格納できることを描き出しています : 
例を挙げれば、文字列、数値型、構造体などです。他の enum を含むことさえできます！また、標 
準ライブラリの型は、あなたが思い付いた可能性のあるものよりも複雑ではないことがしばしばあり 
ます。 

標準ライブラリに IpAddr に対する定義は含まれるものの、標準ライブラリの定義をスコープに導 
入していないので、まだ、干渉することなく自分自身の定義を生成して使用できることに注意してく 
ださい。型をスコープに導入することについては、第 7 章でもっと詳しく言及します。 

リスト 6-2 で enum の別の例を見てみましょう：今回のコードは、幅広い種類の型が列挙子に埋め 
込まれています。 


enum Message { 

Quit, 

Move { x: i32 ， y : i32 }， 
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Wnte(Stri ng ) ， 

ChangeColor (i 32 , i32 , i32 ) , 

} 

リスト 6-2: 列挙子各々が異なる型と量の値を格納する Message enum 

この enum には、異なる型の列挙子が4つあります： 

• Quit には紐付けられたデータは全くなし。 

• Move は、中に匿名構造体を含む。 

• Write は、単独の String オブジェクトを含む。 

• ChangeColor は、3つの i32 値を含む。 

リスト 6-2 のような列挙子を含む enum を定義することは、 enum の場合、 struct キーワードを 
使わず、全部の列挙子が Message 型の元に分類される点を除いて、異なる種類の構造体定義を定義す 
るのと類似しています。以下の構造体も、先ほどの enum の列挙子が保持しているのと同じデータを 
格納することができるでしよう： 

struct QuitMessage; // ユニット構造体 
struct MoveMessage i 
x: i'32, 
y: i32, 

} 

struct WriteMessage(String); // タプル構造体 

struct ChangeColorMessage(i32, i32 , i32) ; // タプル構造体 

ですが、異なる構造体を使っていたら、各々、それ自身の型があるので、単独の型になるリスト 6-2 
で定義した Message enum ほど、これらの種のメッセージいずれもとる関数を簡単に定義することは 
できないでしよう。 

enum と構造体にはもう1点似通っているところがあります： impi を使って構造体にメソッドを定 
義できるのと全く同様に、 enum にもメソッドを定義することができるのです。こちらは、 Message 
enum 上に定義できる call という名前のメソッドです： 


# enum Message { 

# Quit, 

# Move { x: i 32 , y: i32 }, 

# Write (String) , 

# ChangeColor (i32 , i32 , "i32) , 

# } 

# 

impl Message { 

fn call(&self) { 

// method body would be defined here 

// メソッド本体はここに定義される 


} 


} 
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let m = Message: : Wnte(Stnng: : from ("hello") ) : 
m.call(); 

メソッドの本体では、 self を使用して、メソッドを呼び出した相手の値を取得できるでしょう。こ 
の例では、 Message: : Write(String: : f rom( u hello") ) という値を持つ、変数 m を生成したので、これ 
が m.call() を走らせた時に、 call メソッドの本体内で self が表す値になります。 

非常に一般的で有用な別の標準ライブラリの enum を見てみましょう： option です。 

6.1.2 Option enum と Null 値に勝る利点 

前節で、 ipAddr enum が Rust の型システムを使用して、プログラムにデータ以上の情報をコード 
化できる方法を目撃しました。この節では、 Option のケーススタディを掘り下げていきます。この 
型も標準ライブラリにより定義されている enum です。この option 型はいろんな箇所で使用されま 
す。なぜなら、値が何かかそうでないかという非常に一般的な筋書きをコード化するからです。この 
概念を型システムの観点で表現することは、コンパイラが、プログラマが処理すべき場面全てを処理 
していることをチヱックできることを意味します；この機能は、他の言語において、究極的にありふ 
れたバグを阻止することができます。 

プログラミング言語のデザインは、しばしばどの機能を入れるかという観点で考えられるが、除い 
た機能も重要なのです。 Rust には、他の多くの言語にはある null 機能がありません。 null とはそ 
こに何も値がないことを意味する値です。 null のある言語において、変数は常に二者択一どちらかの 
状態になります： null かそうでないかです。 

null の開発者であるトニー-ホーア （Tony Hoare ) の2009年のプレゼンテーション 、 ’’Null 
References : The Billion Dollar Mistake ”( Null 参照： 10 億ドルの間違い）では、こんなことが語 
られています。 

私はそれを10億ドルの失敗と呼んでいます。その頃、私は、オブジェクト指向言語の参照に 
対する、最初のわかりやすい型システムを設計していました。私の目標は、どんな参照の使用 
も全て完全に安全であるべきことを、コンパイラにそのチヱックを自動で行ってもらって保証 
することだったのです。しかし、 null 参照を入れるという誘惑に打ち勝つことができませんで 
した。それは、単純に実装が非常に容易だったからです。これが無数のエラーや脆弱性、シス 
テムクラッシュにつながり、過去40年で10億ドルの苦痛や損害を引き起こしたであろうとい 
うことなのです。 

null 値の問題は、 null の値を null でない値のように使用しようとしたら、何らかの種類のエラー 
が出ることです。この null かそうでないかという特性は広く存在するので、この種の間違いを大変 
犯しやすいのです。 

しかしながら、 null が表現しようとしている概念は、それでも役に立つものです： null は、何らか 
の理由で現在無効、または存在しない値のことなのです。 
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問題は、全く概念にあるのではなく、特定の実装にあるのです。そんな感じなので、 Rust には null 
がありませんが、値が存在するか不在かという概念をコード化する enum ならあります。この enum 
が Option<T> で、以下のように標準ライブラリに定義されています。 

enum Option<T> { 

Some(T) , 

None , 

} 

option く t > は有益すぎて、初期化処理 （ prelude ) にさえ含まれています。つまり、明示的にスコー 
プに導入する必要がないのです。さらに、列挙子もそうなっています： Some と None を Option ::の接 
頭辞なしに直接使えるわけです。ただ、 Option く T> はそうは言っても、普通の enum であり、 Some(T) 
と None も Option<T> 型のただの列挙子です。 

<丁>という記法は、まだ語っていない Rust の機能です。これは、ジヱネリック型引数であり、ジェ 
ネリクスについて詳しくは、第10章で解説します。とりあえず、知っておく必要があることは、く T > 
は、 Option enum の Some 列挙子が、あらゆる型のデータを1つだけ持つことができることを意味し 
ていることだけです。こちらは、 Option 値を使って、数値型や文字列型を保持する例です。 

let some_number = Some(5) ; 

let some_stnng = Some ("a string"); 

let absent_number: 0ption<i32> = None ; 

Some ではなく、 None を使ったら、コンパイラに Option<T> の型が何になるかを教えなければいけ 
ません。というのも、 None 値を見ただけでは、 Some 列挙子が保持する型をコンパイラが推論できな 
いからです。 

Some 値がある時、値が存在するとわかり、その値は、 Some に保持されています。 None 値がある場 
合、ある意味、 null と同じことを意図します：有効な値がないのです。では、なぜ Option<T> の方が、 
null よりも少しでも好ましいのでしょうか？ 

簡潔に述べると、 Option<T> と T (ここで T はどんな型でもいい）は異なる型なので、 コンパイラ 
が Option<T> 値を確実に有効な値かのようには使用させてくれません。例えば、このコードは i8 を 
0ption<i8> に足そうとしているので、 コンパイルで きません。 

let x: 18 = 5; 

let v: 0ption<i8> = Some(5) ; 

let sum = x + y; 

この コー ドを動かしたら、以下のような エラー メッセージが出ます。 


error*[E0277] : the trait bound i8 : std: :ops: :Add<std: :option: :0ption<i8>> is 
not satisfied 
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( エラー： 'i8: std :: ops: : Add く std :: option: :0ption<i8 >>、 というトレイト境界が満たさ 
れていません） 


5 | let sum = x + y; 

| A no implementation tor 18 + std::option::0ption<i8> 

i 

なんて強烈な！実際に、このエラーメッセージは、 i8 と 0ption<i8> が異なる型なので、足し合わ 
せる方法がコ ンパ イラにはわからないことを意味します。 Rust において、 i 8 のような型の値がある 
場合、コンパイラが常に有効な値であることを確認してくれます。この値を使う前に null であること 
をチヱックする必要なく、自信を持って先に進むことができるのです。 0ption<i8> がある時（あるい 
はどんな型を扱おうとしていても）のみ、値を保持していない可能性を心配する必要があるわけであ 
り、コ ン パイラはプログラマが値を使用する前にそのような場面を扱っているか確かめてくれます。 

言い換えると、 T 型の処理を行う前には、 Option<T> を T に変換する必要があるわけです。一般的 
に、これにより、 null の最もありふれた問題の 一つを 捕捉する一助になります：実際には null なの 
に、そうでないかのように想定することです。 

不正確に null でない値を想定する心配をしなくてもよいということは、コード内でより自信を持 
てることになります。 null になる可能性のある値を保持するには、その値の型を Option<T> にするこ 
とで明示的に同意しなければなりません。それからその値を使用する際には、値が null である場合を 
明示的に処理する必要があります。値が Option<T> 以外の型であるとこ全てにおいて、値が null で 
ないと安全に想定することができます。これは、 Rust にとって、意図的な設計上の決定であり 、 null 
の普遍性を制限し、 Rust コードの安全性を向上させます。 

では、 Option<T> 型の値がある時、その値を使えるようにするには、どのように Some 列挙子から T 
型の値を取り出せばいいのでしょうか？ Option<T> には様々な場面で有効に活用できる非常に多くの 
メソッドが用意されています；ドキュメントでそれらを確認できます。 Option<T> のメソッドに馴染 
むと、 Rust の旅が極めて有益になるでしょう。 

一般的に、 Option<T> 値を使うには、各列挙子を処理するコードが欲しくなります。 Some (T) 値が 
ある時だけ走る何らかのコードが欲しくなり、このコードが内部の T を使用できます。 None 値があっ 
た場合に走る別のコードが欲しくなり、そちらのコードは T 値は使用できない状態になります。 match 
式が、 enum とともに使用した時にこれだけの動作をするフロー制御文法要素になります： enum の 
列挙子によって、違うコードが走り、そのコードがマッチした値の中のデータを使用できるのです。 

6.2 match フロー制御演算子 

Rust には、一連のパターンに対して値を比較し、マッチしたパターンに応じてコードを実行させ 
てくれる match と呼ばれる、非常に強力なフロー制御演算子があります。パターンは、リテラル ft 
変数名、ワイルドカードやその他多数のもので構成することができます；第18章で、全ての種類のパ 
ターンと、その目的については解説します。 match のパワーは、パターンの表現力とコンパイラが全 
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てのありうるパターンを処理しているかを確認してくれるという事実に由来します。 

match 式をコイン並べ替え装置のようなものと考えてください：コインは、様々なサイズの穴が空 
いた通路を流れ落ち、各コインは、サイズのあった最初の穴に落ちます。同様に、値は match の各パ 
ターンを通り抜け、値が「適合する」最初のパターンで、値は紐付けられたコードブロックに落ち、 
実行中に使用されるわけです。 

コインについて話したので、それを match を使用する例にとってみましょう！数え上げ装置と同 
じ要領で未知のアメリカコインを一枚取り、どの種類のコインなのか決定し、その価値をセントで返 
す関数をリスト 6-3 で示したように記述することができます。 

enum Coin { 

Penny, 

Nickel, 

Di me, 

Quarter, 

} 

fn value_in_cents(coin: Con n ) -> u32 { 
match coin { 

Coin :: Penny => 1, 

Coin::Nickel=> 5, 

Coin::Dime => 10, 

Coin: : Quarter => 25 ， 



リスト 6-3: enum とその enum の列挙子をパターンにした match 式 

val_ue_in_cents 関数内の match を嚙み砕きましょう。まず、 match キーワードに続けて式を並べ 
ています。この式は今回の場合、値 coin です。 if で使用した式と非常に酷似しているみたいですね。 
しかし、大きな違いがあります： if では、式は論理値を返す必要がありますが、ここでは、どんな型 
でも構いません。この例における coin の型は、1行目で定義した Coin enum です。 

次は、 match アームです。一本のアームには 2 つの部品があります：パターンと何らかのコードで 
す。今回の最初のアームは Coin: :Penny という値のパターンであり、パターンと動作するコードを区 
別する => 演算子が続きます。この場合のコードは、ただの値 1 です。各アームは次のアームとカンマ 
で区切られています。 

この match 式が実行されると、結果の値を各アームのパターンと順番に比較します。パターンに値 
がマッチしたら、そのコードに紐付けられたコードが実行されます。パターンが値にマッチしなけれ 
ば、コイン並べ替え装置と全く同じように、次のアームが継続して実行されます。必要なだけパター 
ンは存在できます：リスト 6-3 では、 match には 4 本のアームがあります。 

各 アーム に紐付けられる コードは 式であり、マッチした アー ムの式の結果が match 式全体の戻り値 
になります。 

典型的に、アームのコードが短い場合、波かっこは使用されません。リスト 6-3 では、各アームが 
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値を返すだけなので、これに倣っています。マッチのアームで複数行のコードを走らせたいのなら、 
波かっこを使用することができます。例えば、以下のコードは、メソッドが Coi n :: Penny とともに呼 
び出されるたびに 「 LuckypennyL と表示しつつ、ブロックの最後の値、 i を返すでしょう。 

# enum Coin i 

# Penny , 

# Nickel , 

# Dime , 

# Quarter , 

# } 

# 

fn value _ in _ cents ( coin : Coin ) -> u 32 { 
match coin { 

Coin :: Penny => { 

println! ("Lucky penny !"); 

1 

}, 

Coi ’ n :: Nickel => 5, 

Coin : :Dime => 10, 

Coin: : Quarter => 25, 



6.2.1 値に束縛されるパターン 

マッチのアームの別の有益な機能は、パターンにマッチした値の一部に束縛できる点です。こうし 
て、 enum の列挙子から値を取り出すことができます。 

例として、 enum の列挙子の 一つを 中にデータを保持するように変えましょう。1999年から2008 
年まで、アメリカは、片側に50の州それぞれで異なるデザインをしたクォーターコインを铸造して 
いました。他のコインは州のデザインがなされることはなかったので、クォーターだけがこのおまけ 
の値を保持します。 Quarter 列挙子を変更して、 UsState 値が中に保持されるようにすることで enum 
にこの情報を追加でき、それをしたのがリスト 6-4 のコードになります。 

#[ derive ( Debug )] //卞 ぐに州を点検できるように 

enum UsState { 

Alabama , 

Alaska , 

H ." などなど 

} 


enum Coin { 

Penny , 

Nickel , 

Di me , 

Quarter ( UsState ), 


} 
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リスト 6-4： Quarter 列挙子が UsState の値も保持する Coin enum 

友人の一人が50州全部のクォーターコインを収集しようとしているところを想像しましょう。コ 
インの種類で小銭を並べ替えつつ、友人が持っていない種類だったら、コレクションに追加できるよ 
うに、各クォーターに関連した州の名前を出力します。 

このコードの match 式では、 Coin : :Quarter 列挙子の値にマッチする state という名の変数をパ 
ターンに追加します。 Coin : : Quarter がマッチすると、 state 変数はそのクォーターの State の値に 
束縛されます。それから、 state をそのアームのコードで使用できます。以下のようにですね： 

# # [derive(Debug)] 

# enum UsState { 

# Alabama, 

# Alaska , 

# } 

# 

# enum Coin { 

# Penny , 

# Nickel , 

# Dime , 

# Quarter ( UsState ), 

# } 

# 

fn value _ in _ cents ( coin : Coin ) -> u 32 { 
match coin { 

Coin :: Penny => 1, 

Coin :: Nickel => 5, 

Coin : :Dime => 10, 

Coin : : Quarter ( state ) => { 

println! ("State quarter from {:?}!", state ); 

25 

}, 



value_i n_cents (Coi n :: Quarter ( UsState :: Alaska )) と呼び出すつもりだったなら、 coin は Coin 
:: Quarter ( UsState : : Alaska ) になります。その値を match の各アームと比較すると、 Coin : : Quater 
( state ) に到達するまで、どれにもマッチしません。その時に、 state に束縛されるのは、 UsState :: 
Alaska という値です。そして、 println ! 式でその束縛を使用することができ、そのため、 Coin enum 
の列挙子から Quarter に対する中身の State の値を取得できたわけです。 

6.2.2 Opti on < T > とのマッチ 

前節では、 Option < T > を使用する際に、 Some ケースから中身の T の値を取得したくなりました。要 
するに、 Coin enurn に対して行ったように、 match を使って Option < T > を扱うこともできるという 
わけです！コインを比較する代わりに、 Option < T > の列挙子を比較するのですが、 match 式の動作の 
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仕方は同じままです。 

0 ption < i 32> を取る関数を書きたくなったとし、中に値があったら、その値に1を足すことにしま 
しょう。中に値がなければ、関数は None 値を返し、何も処理を試みるべきではありません。 
match のおかげで、この関数は大変書きやすく、リスト 6-5 のような見た目になります。 


fn plus_one(x : 0ption<-i32>) -> 0ption<i32> { 
match x { 

None => None, 

Some ⑴ => Some ぃ + 1 )， 



let rive = Some (5) ; 

let six = plus _ one ( tive ); 

let none = plus _ one ( None ); 

リスト 6 - 5 : 0 ption < i 32> に match 式を使う関数 

plus _ one の最初の実行についてもっと詳しく検証しましょう。 plus _ one ( five ) と呼び出した時、 
plus _ one の本体の変数 x は Some (5) になります。そして、これをマッチの各アームと比較します。 

None => None , 

Some (5) という値は、 None というパターンにはマッチしませんので、次のアームに処理が移ります。 
Some ⑴=> Some(i + 1)， 

Some (5) は Some ( i ) にマッチしますか？なんと、します！列挙子が同じです。 i は Some に含まれ 
る値に束縛されるので、 i は値5になります。それから、このマッチのアームのコードが実行される 
ので、 i の値に1を足し、合計の6を中身にした新しい Some 値を生成します。 

さて、 x が None になるリスト 6-5 の2回目の plus _ one の呼び出しを考えましょう。 match に入り、 
最初のアームと比較します。 

None => None , 


マッチします！足し算する値がないので、プログラムは停止し、=> の右辺にある None 値が返りま 
す。最初のアームがマッチしたため、他のアームは比較されません。 

match と enum の組み合わせは、多くの場面で有効です。 Rust コードにおいて、このパターンは 
よく見かけるでしょう： enum に対し match し、内部のデータに変数を束縛させ、それに基づいた 
コードを実行します。最初はちょっと巧妙ですが、一旦慣れてしまえば、全ての言語にあってほしい 
と願うことになるでしょう。一貫してユーザのお気に入りなのです。 
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6.2.3 マッチは包括的 

もう一つ議論する必要のある match の観点があります。一点バグがありコンパイルできないこんな 
バージョンの plus_one 関数を考えてください： 

fn plus_one(x : 0ption<i32>) -> 0ption<i32> { 
match x i 

Some ⑴ => Some(i + 1)， 

} 

} 

None の場合を扱っていないため、このコードはバグを生みます。幸い、コンパイラが捕捉できるバ 
グです。このコードのコンパイルを試みると、こんなエラーが出ます： 

error[E0004] : non-exhaustive patterns : None not covered 
(エラー： 包括的でないパターン ：' None 、がカバーされてません） 

—— > 

I 

6 | match x i 

| a pattern 'None not covered 

全可能性を網羅していないことをコンパイラは検知しています。もっと言えば、どのパターンを忘 
れているかさえ知っているのです。 Rust におけるマッチは、包括的です：全てのあらゆる可能性を網 
羅し尽くさなければ、コードは有効にならないのです。特に OptiorKT 〉 の場合には、コンパイラが明 
示的に None の場合を扱うのを忘れないようにする時、 null になるかもしれない値があることを想定 
しないように、故に、前に議論した10億ドルの失敗を犯さないよう、保護してくれるわけです。 

6.2.4 _というプレ_スホルダー 

Rust には、全ての可能性を列挙したくない時に使用できるパターンもあります。例えば、 U 8 は、有 
効な値として、0から255までを取ります。1、3、5、7の値にだけ興味があったら、0、2、4、6、 
8、9と255までの数値を列挙する必要に迫られたくはないです。幸運なことに、する必要はありま 
せん：代わりに特別なパターンの _ を使用できます： 

let some_u8_value = 0u8 ; 
match some_u8_value i 

1=> println! ("one") , 

3 => println! ("three") , 

5 => println! ("five") , 

7 => println! ("seven") , 

_=>()， 

} 

_ というパターンは、どんな値にもマッチします。他のアームの後に記述することで、_は、それ 
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までに指定されていない全ての可能性にマッチします。 （） は、ただの ユニット 値なので、_の場合に 
は、何も起こりません。結果として、_プレースホルダーの前に列挙していない可能性全てに対して 
は、何もしたくないと言えるわけです。 

ですが、一つのケースにしか興味がないような場面では、 match 式はちょっと長ったらしすぎます。 
このような場面用に、 Rust には、 if let が用意されています。 

6.3 if let で簡潔なフロー制御 

if let 記法で if と let をより冗長性の少ない方法で組み合わせ、残りを無視しつつ、一つのパ 
ターンにマッチする値を扱うことができます。 0 ption < u 8> にマッチするけれど、値が 3 の時にだけ 
コードを実行したい、リスト 6-6 のプログラムを考えてください。 

let some _ u 8 _value = Some (0 u 8) ; 
match some _ u 8 _value i 

Some (3) => println ! (" three ") , 

- => 0 , 

} 

リスト 6-6: 値が Some (3) の時だけコードを実行する match 

Some (3) にマッチした時だけ何かをし、他の Some < u 8> 値や None 値の時には何もしたくありませ 
ん。 match 式を満たすためには、列挙子を一つだけ処理した後に_ => () を追加しなければなりませ 
ん。これでは、追加すべき定型コードが多すぎます。 

その代わり、 if let を使用してもっと短く書くことができます。以下のコードは、リスト 6-6 の 
match と同じように振る舞います： 


# let some _ u 8 _value = bome (0 u 8) ; 
if let Some (3) = some _ u 8 _value { 
println ! (" three ") ; 

} 

if let という記法は等号記号で区切られた パターンと 式を取り、式が match に 与えられ、 パターン 
が最初の アームに なった match と、同じ動作をします。 

if let を使うと、タイプ数が減り、インデントも少なくなり、定型コードも減ります。しかしなが 
ら、 match では強制された包括性チヱックを失ってしまいます。 match か if let かの選択は、特定の 
場面でどんなことをしたいかと簡潔性を得ることが包括性チエックを失うのに適切な代償となるかに 
よります。 

言い換えると、 if let は値が一つのパターンにマッチした時にコードを走らせ、他は無視する 
match への糖衣構文と考えることができます。 

if let では、 else を含むこともできます。 else に入るコードブロックは、 if let と else に等価 
な match 式の_の場合に入るコードブロックと同じになります。リスト 6-4 の coin enum 定義を思 
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い出してください。ここでは、 Quarter ■列挙子は、 UsState の値も保持していましたね。クォーター 
コインの状態を告げつつ、見かけたクォーター以外のコインの枚数を数えたいなら、以下のように 
match 式で実現することができるでしよう： 

# # [ derive ( Debug )] 

# enum UsState { 

# Alabama, 

# Alaska , 

# } 

# 

# enum Coin { 

# Penny , 

# Nickel , 

# Dime , 

# Quarter ( UsState ), 

# } 

# let coin = Coin : : Penny ; 
let mut count = 0; 
match coin { 

// {: ?} 州のクォーターコイン 

Coin : : Quarter ( state ) => println! ("State quarter from {:?}!", state ), 

_ => count +=1, 

} 

または、以下のように if let と else を使うこともできるでしよう： 

# # [ derive ( Debug )] 

# enum UsState { 

# Alabama, 

# Alaska , 

# } 

# 

# enum Coin { 

# Penny , 

# Nickel , 

# Dime , 

# Quarter ( UsState ), 

# } 

# let coin = Coin :: Penny ; 
let mut count = 0; 

if let Coin : : Quarter ( state ) = coin { 

println! ("State quarter from {:?}!", state ); 

} else { 

count +=1; 

} 

match を使って表現するには冗長的すぎるロジックがプログラムにあるようなシチュエーションに 
遭遇したら 、 if let も Rust 道具箱にあることを思い出してください。 
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6.4 まとめ 

これで、 enum を使用してワンセットの列挙された値のどれかになりうる独自の型を生成する方法 
を講義しました。標準ライブラリの 0 ption < T > が型システムを使用して、エラーを回避する際に役立 
つ方法についても示しました。 enum の値がデータを内部に含む場合、処理すべきケースの数に応じ 
て、 match か if let を使用して値を取り出し、使用できます 0 

もう Rust プログラムで構造体と enum を使用して、自分の領域の概念を表現できます。 API 内で 
使用するために独自の型を生成することで、型安全性を保証することができます：コンパイラが、各 
関数の予期する型の値のみを関数が得ることを確かめてくれるのです。 

使用するのに率直な整理整頓された API をユーザに提供し、ユーザが必要とするものだけを公開す 
るために、今度は、 Rust のモジュールに目を向けてみましょう。 



モジュールを使用してコードを体系化 
し、再利用する 


Rust でのプログラミングをし始めた頃は、コードは全て main 関数内に収まったかもしれません。 
コードが肥大化するにつれ、最終的に機能を別の関数に移して再利用性とまとまりを高めるでしょう。 
コードを細切りにすることで、個々のコード片をそれだけで理解しやすくします。しかし、あまりに 
も多くの関数があったらどうなるでしょうか？ Rust には、コードの再利用を体系化された形で行う 
ことのできるモジュールシステムが組み込まれています。 

コードを関数に抽出するのと同様に、関数（や他のコード、構造体や enum など）を異なるモジュー 
ルに抽出することができます。モジュールとは、関数や型定義を含む名前空間のことで、それらの定 
義がモジュール外からも見えるようにするか ( public ) 否か （ private ) は、選択することができます。 
以下が、モジュールの動作法の概要です： 

• mod キーワードで新規モジュールを宣言します。モジュール内のコードは、この宣言の直後の 
波かっこ内か、別のファイルに存在します。 

• 標準では、関数、型、定数、モジュールは非公開です。 pub キーワードで要素は公開され、名 
前空間の外からも見えるようになります。 

• use キーワードでモジュールやモジュール内の定義をスコープに入れることができるので、参 
照するのが楽になります。 

この各部品を見て、それらが全体にどうはまり込むかを理解します。 

7.1 mod とファイルシステム 


モジュールの例を Cargo で新規プロジェクトを生成することから始めるが、バイナリクレートの 
代わりに、ライブラリクレートを作成します：他人が依存として自分のプロジェクトに引き込めるプ 
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ロジヱクトです。例を挙げると、第2章で議論した rand クレートは、数当てゲームプロジェクトで 
依存に使用したライブラリクレートです。 

何らかの一般的なネットワーク機能を提供するライブラリの骨格を作成します；モジュールと関数 
の体系化に集中し、関数の本体にどんなコードが入るかについては気にかけません。このライブラリ 
を communicator と呼びましよう。ライブラリを生成するために、 -- bin の代わりに -- lib オプション 
を渡してください： 

$ cargo new communicator --lib 
$ cd communicator 

Cargo が src/main.rs の代わりに src/lib.rs を生成したことに注目してください。 src/lib.rs に 
は、以下のような記述があります： 

ファイル名： src / lib.rs 


# [ cfg ( test )] 
mod tests { 

#[ test ] 

fn it _ works () { 

assert _ eq ! (2 +2， 4); 



Cargo は、 -- bin オプションを使った時に得られる’’ Hello , world !” バイナリではなく、空のテス 
卜を生成して、ライブラリの事始めをしてくれました〇 #[] と mod tests という記法については、こ 
の章の後ほど、 「 super •を使用して親モジュールにアクセスする」節で見ますが、今のところは、この 
コードを src/lib.rs の最後に残しておきましょう。 

src/main.rs ファイルがないので 、 cargo run コマンドで Cargo が実行できるものは何もないわ 
けです。従って 、 cargo build コマンドを使用してライブラリクレートのコードをコンパイルします。 

コードの意図によって、いろんなシチュエーションで最適になるライブラリコードを体系化する別 
のオプションをお目にかけます。 

7.1.1 モジュール定義 

communi cator ネットワ^ークライブラリについて、まずは connect という関数定義を含む network 
という名前のモジュールを定義します。 RllSt において、モジュール定義は全て、 mod キーワードから 
開始します。このコードを src/lib.rs ファイルの頭、テストコードの上に追記してください。 

ファイル名： src / lib.rs 


mod network { 

fn connect () { 



第 7 章モジュールを使用してコードを体系化し、再利用する 


123 


} 

mod キーワードに続いて、モジュール名の network 、 さらに~■連のコードを波かっこ内に記述し 
ます。このブロック内に存在するものは全て、 network という名前空間に属します。今回の場合、 
connect という単独の関数があります〇この関数を network モジュール外のスクリプトから呼び出 
したい場合、モジュールを指定し、以下のように名前空間記法の：：を使用する必要があるでしょう： 
network: : connectu 〇 

同じ src / lib . rs ファイル内に複数のモジュールを並べることもできます。例として、 connect と 
いう関数を含む client モジュールも用意するには、リスト 7-1 に示したように追記すればいいわけ 
です。 

ファイル名： src / lib.rs 

mod network i 

rn connect () { 

} 

} 

mod client { 

fn connect () { 

} 

} 

リスト 7-1: src / lib . rs に並べて定義された network モジュ^ールと client モジュ^ール 

これで、 network : : connect 関数と client : : connect 関数が用意できました。これらは全く異なる 
機能を有する可能性があり、異なるモジュールに存在するので、関数名がお互いに衝突することはあ 
りません。 

今回の場合、ライブラリを構成しているので、ライブラリビルド時にエントリーポイントとなる 
ファイルは、 src / lib . rs になります。しかし、モジュールを作成するという点に関しては、 src / lib.rs 
には何も特別なことはありません。ライブラリクレートに対して src / lib . rs にモジュールを生成する 
のと同様に、バイナリクレートに対して src / main . rs にモジュールを生成することもできます。実 
は、モジュール内にモジュールを書くこともでき、モジュールが肥大化するにつれて、関連のある機 
能を一緒くたにし、機能を切り離すのに有用なのです。コードを体系化すると選択する方法は、コー 
ドの部分部分の関連性に対する考え方によります。例ですが、 client コードとその connect 関数は、 
リスト 7-2 のように、代わりに network 名前空間内に存在したら、ライブラリの使用者にとって意味 
のあるものになるかもしれません。 

ファイル名： src / lib.rs 


mod network { 

fn connect 〇 { 
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} 

mod client { 

fn connect() { 
} 



リスト 7-2； client モジュールを network モジュール内に移動させる 

SF c/lib.FS フアイル内で、すでにある mod network と mod client の定義をリスト 7-2 のものと 
置き換えると、 client モジュールは network の内部モジュールになるわけです。関数、 network : : 
connect と network : : client : : connect はどちらも connect という名前ですが、異なる名前空間にあ 
るので、互いに干渉することはありません。 

このように、モジュールは階層構造を形成します。 src/lib.rs の中身が頂点に立ち、サブモジュー 
ルが子供になるわけです。リスト 7-1 の例を階層構造という観点で見たときの構造は、以下のような 
感じになります： 

commumcator 

I - network 

1 - client 

さらに、リスト 7-2 の例に対応する階層構造は、以下の通りです： 

commumcator 

1 - network 

1 - client 

この階層構造は、リスト 7-2 において、 client モジュールは network モジュールの兄弟というよ 
りも、子供になっていることを示しています。より複雑なプロジェクトなら、たくさんのモジュール 
が存在し、把握するのに論理的に体系化しておく必要があるでしょう。プロジヱクト内で「論理的」 
とは、あなた次第であり、ライブラリ作成者と使用者がプロジェクトの領域についてどう考えるか次 
第でもあるわけです。こちらで示したテクニックを使用して、並列したモジュールや、ネストしたモ 
ジュールなど、どんな構造のモジュールでも、作成してください。 


7.1.2 モジュールを別ファイルに移す 

モジュールは階層構造をなす……コンピュータにおいて、もっと見慣れた構造に似ていませんか: 
そう、ファイルシステムです！ Rust のモジュールシステムを複数のファイルで使用して、プロジェ 
クトを分割するので、全部が src / lib . rs や src / main . rs に存在することにはならなくなります。こ 
れの例として、リスト 7-3 のようなコードから始めましょう。 


ファイル名： src / lib.rs 
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mod client { 

fn connect () { 

} 

} 

mod network { 

fn connect () { 

} 

mod server { 

fn connect () { 
} 



リスト 7-3； 全て Src/lib.rS に定義された二つのモジュール、 client 、 network 、 network : : server 

src/lib.rs ファイルのモジュール階層は、こうなっています： 

commumcator 

I - c nent 

1 - network 

1 - server 

これらのモジュールが多数の関数を含み、その関数が長ったらしくなってきたら、このファイルを 
スクロールして、弄りたいコードを探すのが困難になるでしょう。関数が一つ以上の mod ブロック 
にネストされているので、関数の中身となるコードも長ったらしくなってしまうのです。これだけで、 
client 、 network 、 server モジュールを Src/lib.FS から分け、単独のファイルに配置するには十分 
でしょう。 

最初に、 client モジュールのコードを client モジュールの宣言だけに置き換えましょう。すると、 
src/lib.rs はリスト 7-4 のコードのようになります。 

ファイル名： src / lib.rs 

mod client ; 

mod network i . 

fn connect () { 

} 

mod server { 

fn connect () { 

} 



リスト 7-4: client モジュールの中身を抽出するが、宣言は src/lib.rs に残したまま 
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一応、 client モジュールをここで宣言していますが、ブロックをセミコロンで置換したことで、 
client モジュ ー ルのス コープのコード は別の場所を探すようにコンパイラに指示しているわけです。 
言い換えると、 mod client; の行は、以下のような意味になります： 


mod client i 

II contents of c uent. rs 

} 

さて、このモジュール名の外部ファイルを作成する必要が出てきました。 src / ディレクトリ内に 
client . rs ファイルを作成し、開いてください。それから以下のように入力してください。前段階で 
削除した client モジュールの connect 関数です： 

ファイル名： src / client.rs 

fn connect() { 

} 


このファイルには、 mod 宣言が必要ないことに着目してください。なぜなら、 src / lib . rs に mod を 
使って、もう client モジュールを宣言しているからです。このファイルは、 client モジュールの中 
身を提供するだけなのです。ここにも mod client を記述したら、 client に client という名前のサ 
ブモジュールを与えることになってしまいます！ 

コンパイラは、標準で src / lib . rs だけを検索します。プロジェクトにもっとファイルを追加した 
かったら、 src / lib . rs で他のファイルも検索するよう、コンパイラに指示する必要があるのです；こ 
のため、 mod client を src / lib . rs に定義し、 src / client . rs には定義できなかったのです。 

これでプロジェクトは問題なくコンパイルできるはずです。まあ、警告がいくつか出るんですが。 
cargo run ではなく、 cargo build を使うことを忘れないでください。バイナリクレートではなく、 
ライブラリクレートだからですね： 


$ cargo build 

Compiling communicator v0.1.0 (file:///proiects/communicator) 

warning: function is never used : 'connect' 

( 警告：関数は使用されていません： 'connect') 

-- > src/client.rs:l:l 

I 

1 | / fn connect() { 


=note : #[warn(dead_code)] on by default 

warning: function is never used : 'connect' 
--> src/lib.rs:4:5 


4 | / 


fn connect() { 
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5 | | 


warning : function is never used : connect 
--> src / lib . rs :8:9 

I 

8 | / fn connect () { 

9 I I > 


これらの警告は、全く使用されていない関数があると忠告してくれています。今は、警告を危惧す 
る必要はありません；この章の後ほど、 「 pub で公開するか制御する」節で扱います。嬉しいことにた 
だの警告です；プロジェクトはビルドに成功しました！ 

次に、同様のパターンで network モジュールも単独のファイルに抽出しましよう。 src/lib.rs で、 
network モジュールの本体を削除し、宣言にセミコロンを付加してください。こんな感じです： 

ファイル名： src/lib.rs 

mod client ; 

mod network ; 

それから新しい src/network.rs ファイルを作成して、以下のように入力してください： 

ファイル名： src/network.rs 

fn connect () i 
} 


mod server { 

fn connect () { 

} 

} 

このモジュールファイル内にもまだ mod 宣言があることに気付いてください； server はまだ 
network のサブモジュールにしたいからです。 

再度 cargo build してください。成功！抽出すべきモジュールがもう1個あります： server です。 
これはサブモジュール（つまり、モジュール内のモジュール）なので、モジュール名に倣ったファイル 
にモジュールを抽出するという今の手法は、通用しません。いずれにしても、エラーが確認できるよ 
うに、試してみましょう。まず、 src/network.rs フ ァイルを server モジュールの中身を含む代わ 
りに 、 mod server ; となるように変更してください。 

フアイル名： src/network.rs 


fn connect () { 
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} 

mod server ; 


そして、 src/server.rs ファイルを作成し、抽出した server ■モジュールの中身を入力してくだ 
さい： 

フアイル名： src/server.rs 

rn connect() i 

} 

cargo build を実行しようとすると、リスト 7-5 に示したようなエラーが出ます： 

^ cargo buila 

Compiung communicator* v0.1.0 (fi ie : / //projects/commumcator) 
error: cannot declare a new module at this location 
( エラー：この箇所では新規モジュールを宣言できません） 

-- > src/network.rs:4:5 

I 

4 | mod server; 

| A A A A A A 

I 

note : maybe move this module 'src/network.rs' to its own directory via 'src/ 
network/mod.rs' 

( 注釈：もしかして 、 ' src/network. rs' というこのモジュールを ' src/network/mod • rs 、 経 
由で独自のディレクトリに移すの） 

-- > src/network.rs :4:5 

I 

4 | mod server ; 

| A A A A A A 

note : ... or maybe 'use' the module 'server' instead of possibly redeclaring it 
( 注釈：それとも、再度宣言する可能性はなく、 'server' というモジュールを 'use ' したの 
) 

-- > src/network.rs :4:5 

I 

4 | mod server ; 


リスト 7-5: server サブモジュールを src / server . rs に抽出しようとしたときの エラー 

エラーは、 この箇所では新規モジュールを宣言できません と忠告し、 src / netw 0 rk . rs の mod server*; 行を 
指し示しています。故に、 src / network . rs は、 src / lib . rs と何かしら違うのです：理由を知るため 
に読み進めましょう。 

リスト 7-5 の真ん中の注釈は、非常に有用です。というのも、まだ話題にしていないことを指摘し 
ているからです。 


note : maybe move this module network to its own directory via 
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network / mod.rs 

以前行ったフアイル命名パターンに従い続けるのではなく、注釈が提言していることをすることが 
できます： 

1. 親モジュール名である network という名前の新規ディレクトリを作成する。 

2. src/network.rs フアイルを network ディレクトリに移し、 src/network/mod.rs と名前 

を変える。 

3. サブモジュールフアイルの src/server.rs を network デイレクトリに移す。 


以下が、これを実行するコマンドです： 

5 mkcn r src/network 

^ mv src / network.rs src / network / mod.rs 
$ mv src / server.rs src/network 

cargo build を走らせたら、コンパイルは通ります（まだ警告はありますけどね)。それでも、モ 
ジュールの配置は、リスト 7-3 で src/lib.rs に全てのコードを収めていたときと全く同じになり 
ます： 


commum cator 

I - client 

1 - network 

1 - server 

対応するファイルの配置は、以下のようになっています： 

1 - src 

I - client.rs 

I - lib.rs 

1 - network 

I - mod.rs 

1 - server.rs 

では、 network : : server ■モジュールを抽出したかったときに、なぜ、 Src/netWOrk.rS ファイル 
を src/network/mod.rs ファイルに変更し、 network ： : server のコードを network ディレクトリ 
内の src/network/server.rs に置かなければならなかったのでしょうか？なぜ、単に network ： : 
server モジュールを src/server.rs に抽出できなかったのでしょうか？理由は、 server.rs ファイ 
ルが SFC ディレクトリにあると、コンパイラが、 server は network のサブモジュールと考えられる 
ことを検知できないからです。ここでのコンパイラの動作をはっきりさせるために、以下のようなモ 
ジュール階層をもつ別の例を考えましょう。こちらでは、定義は全て src/lib.rs に存在します。 

commumcator 

I - client 

1 - network 
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1 - client 

この例でも、モジュールは3つあります： client 、 network 、 network : : client です。以前と 
同じ手順を経てモジュールをファイルに抽出すると、 client モジュール用に src / client.rs を作 
成することになるでしょう。 network モジュールに関しては、 src / network.rs を作成します。し 
かし、 network : : client モジュールを Src / clieilt.rS ファイルに抽出することはできません。もう 
トツプ階層の client モジュールとして存在するからです！ client と network : : client 双方のコー 
ドを src / client.rs ファイルに書くことができたら、コンパイラは、コードが client 用なのか、 
network : : client 用なのか知る術を失ってしまいます。 

従って、 network モジュールの network : : cli ent サブモジュールをフアイルに抽出するには、 
src / network.rs ファイルではなく、 network モジュールのディレクトリを作成する必要があったわ 
けです。そうすれば、 network モジュールのコードは、 src / network / mod.rs ファイルに移ること 
になり、 network : : cli ent というサブモジュールは専用の src / network/cli ent . rs ファイルを持てる 
わけです。これで、頂点にある src / client.rs は間違いなく、 client モジュールに属するコードにな 
るわけです。 

7.1.3 モジュールファイルシステムの規則 

ファイルに関するモジュール規則をまとめましょう： 

• foo という名前のモジュールにサブモジュールがなければ、 foo の定義は、 foo.rs というファ 
イルに書くべきです。 

• foo というモジュールに本当にサブモジュールがあったら、 foo の定義は、 foo / mod.rs とい 
うファイルに書くべきです。 

これらのルールは再帰的に適用されるので、 foo というモジュールに bar というサブモジュールが 
あり、 bar •にはサブモジュールがなければ、 SIT ディレクトリには以下のようなファイルが存在する 
はずです： 

I - foo 

I I - bar . rs (' foo : : bar ' 内の定義を含む） 

I 1 - mod . rs ('mod bar ' を含む、 ' foo ' 内の定義を含む） 

モジュールは、親モジュールのファイル内で mod キーワードを使って宣言されるべきなのです。 
次は、 pub キーワードについて話し、警告を取り除きます！ 

7.2 pub で公開するか制御する 

リスト 7-5 に不 した エラーメ ツセージを network と network : : server のコー ドを、 

src / network / mod.rs と src / network / server.rs ファイルにそれぞれ移動することで解決 
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しました。その時点で cargo build はプロジェクトをビルドできましたが、 client :: connect と 
network: : connect と network: : server : : connect 関数が、使用されていないという警告メッセージ 
が出ていました： 


warning: function is never used : connect 
--> src/client.rs:l:l 


/ fn connect() { 

I > 

L A 

note : #[warn(dead_code)] on by default 


warning: function is never used : 'connect 
--> sre/network/mod.rs : 1 : 1 

I 

1 | / fn connect() { 

2 | | } 

I l- A 

warning: function is never used : 'connect 
--> sre/network/server.rs : 1 : 1 

I 

1 | / fn connect() { 

2 I I } 

I I A 


では、何故このような警告を受けているのでしょうか？結局のところ、必ずしも自分のプロジェク 
卜内ではなく、利用者に利用されることを想定した関数を含むライブラリを構成しているので、これ 
らの connect 関数が使用されていかないということは、問題になるはずはありません。これらの関数 
を生成することの要点は、自分ではなく、他のプロジェクトで使用することにあるのです。 

このプログラムがこのような警告を引き起こす理由を理解するために、外部から communicator ラ 
イブラリを呼び出して、他のプロジェクトからこれを使用してみましょう。そうするには、以下のよ 
うな コード を含む src / main . rs を作成して、ライブラリクレートと同じディレクトリにパイナリク 
レートを作成します。 

フアイル名： src/main.rs 
extern crate communicator; 
fn mann() { 

communicator :: client :: connect(); 

} 


extern crate コマンド を使用して、 communicator ライブラリクレートをスコープに導入していま 
す。パッケージには2つのクレートが含まれるようになりました。 Cargo は、 src / main . rs をバイ 
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ナリクレートのルートファイルとして扱い、これはルートファイルが src / lib . rs になる既存のライブ 
ラリクレートとは区別されます。このパターンは、実行形式プロジェクトで非常に一般的です：ほと 
んどの機能はライブラリクレートにあり、バイナリクレートはそれを使用するわけです。結果として、 
他のプログラムもまたこのライブラリクレートを使用でき、良い責任の分離になるわけです。 

communi cator ライブラリの外部のクレートが検索するという観点から言えば、これまでに作って 
きたモジュールは全て、 communicator というクレートと同じ名前を持つモジュール内にあります。ク 
レ ー トのトツプ階層のモジュ ー ルを ル _ ト モジュ _ ル と呼びます。 

プロジェクトのサブモジュール内で外部クレートを使用しているとしても、 extern crate はルー 
トモジュール（つまり、 src / main . rs 、 または src / lib . rs ) に書くべきということにも、注目してくだ 
さい。それから、サブモジュールで外部クレートの要素をトツプ階層のモジュールかのように参照で 
きるわけです。 

現状、バイナリクレートは、 client モジュールからライブラリの connect 関数を呼び出しているだ 
けです。ところが、 cargo build を呼び出すと、警告の後にエラーが発生します： 

error[E0603] : module client is private 

(エラー： ' cli ent 、モジュールは非公開です） 

--> src/main.rs:4:5 

I 

4 | communicator: : client: : connect(); 

| 八八八八八八八八八八八八八八八八八八八八八 A 八八八八八八八 

ああ！このエラーは、 client モジュールが非公開であることを教えてくれ、それが警告の肝だっ 
たわけです。 Rust の文脈において、公開とか非公開という概念にぶち当たったのは、これが初めてで 
もあります。全コードの初期状態は、非公開です：誰も他の人はコードを使用できないわけです。プ 
ログラム内で非公開の関数を使用していなければ、自分のプログラムだけがその関数を使用すること 
を許可された唯一のコードなので、コンパイラは関数が未使用と警告してくるのです。 

client: : connect のような関数を公開にすると指定した後は、バイナリクレートからその関数への 
呼び出しが許可されるだけでなく、関数が未使用であるという警告も消え去るわけです。関数を公開 
にすれば、コンパイラは、関数が自分のプログラム外のコードからも使用されることがあると知りま 
す。コンパイラは、関数が「使用されている」という架空の外部使用の可能性を考慮してくれます。 
それ故に、関数が公開とマークされれば、コンパイラはそれが自分のプログラムで使用されるべきと 
いう要求をなくし、その関数が未使用という警告も止めるのです。 

7.2.1 関数を公開にする 

コンパイラに何かを公開すると指示するには、定義の先頭に pub キーワードを追記します。今は、 
client : : connect が未使用であるとする警告とバイナリークレートの モジュール、 cli ent 、が非公開である 
エラーの解消に努めます。 src / lib . rs を弄って、 client モジュールを公開にしてください。そう、こ 
んな感じに： 
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ファイル名： src / lib.rs 
pub mod client; 
mod network; 

pub キーワードは、 mod の直前に配置されています。再度ビルドしてみましょう： 

error*[E0603] : function connect is private 
--> src/main.rs:4:5 

I 

4 | communicator::client::connect(); 

| AAAAAAAAAAAAAAAAAAAAAAAAAAAAA 

やった！違うエラーになりました！そうです、別のエラーメッセージは、祝杯を上げる理由に 
なるのです。新エラーは、関数、 connect' は非公開ですと示しているので、 src / clieiit . rs を編集して、 
client : : connect も公開にしましょう： 

ファイル名： src / client.rs 

pub fn connect() { 

} 


さて、再び、 cargo build を走らせてください: 


warning: function is never used : connect 
--> src/network/mod.rs:1:1 


/ fn connect() { 

I > 

L A 

note : #[warn(dead_code)] on by default 


warning: function is never used : 'connect 
--> sre/network/server.rs:1:1 

I 

1 | / fn connect() { 

2 I I } 

I I A 


コードのコンパイルが通り、 client:connect が使用されていないという警告はな くなりました！ 
コード未使用警告が必ずしも、コード内の要素を公開に しな ければ なら ないことを示唆している わ 
けでは あり ません：これらの関数を公開 API の一部に したくなかったら、 未使用コード警告がもう必 
要な く、 安全に削除できるコードに注意を向けて く れている可能性も あります。また 未使用コード警 
告は、ライブラリ内でこの関数を呼び出している箇所全てを誤って削除した場合に、バグに目を向け 
させて く れている可能性も あります。 
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しかし今回は、本当に他の 2 つの 関数もク レートの 公開 API にしたい ので、 これも pub と マーク 
して残りの警告を除去しましょう。 src / network / mod.rs を変更して以下のようにしてください： 

フアイル名： src / network / mod.rs 


pub fn connectu { 

} 

mod server; 

そして、コードをコンパイルします： 

warning: function is never used : 'connect 
--> src/network/mod.rs:1:1 

I 

1 | / pub fn connect() { 



=note : #[warn(dead_code)] on by default 

warning: function is never used : 'connect' 
--> src/network/server.rs:1:1 

I 

1 | / fn connect() { 

2 | | } 


んん 一、 nework: :connect は pub に設定されたにもかかわらず、まだ未使用関数警告が出ます。そ 
の理由は、関数はモジュール内で公開になったものの、関数が存在する network モジュールは公開で 
はないからです。今回は、ライブラリの内部から外に向けて作業をした一方、 client: wonnect では、 
外から内へ作業をしていました。 src / lib.rs を変えて network も公開にする必要があります。以下の 
ように： 

ファイル名： src / lib.rs 

pub mod client; 


pub mod network; 


これで コンパイル すれば、あの警告はなくなります: 


warning: function is never used : connect 
--> src/network/server.rs:1:1 


1 | / fn connect() { 
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= note : # [ warn ( dead _ code ) 」 on by default 
残る警告は 1 つなので、自分で解消してみてください！ 

7.2.2 プライバシー規則 

まとめると、要素の公開性は以下のような ルールに なります： 

• 要素が公開なら、どの親モジュールを通してもアクセス可能です。 

• 要素が非公開なら、直接の親モジュールとその親の子モジュールのみアクセスできます。 

7.2.3 プライバシー例 

もうちょっと鍛錬を得るために、もういくつかプライバシー例を見てみましょう。新しいライブ 
ラリプロジェクトを作成し、リスト 7-6 のコードを新規プロジェタトの src / lib . rs に入力してくだ 
さい。 

ファイル名： src/lib.rs 

mod outermost { 

pub fn middle _ function () {} 

fn middle _ secret _ function () {} 

mod insi.de { 

pub fn inner _ function () {} 
fn secret _ function () {} 

} 

} 

fn try _ me () { 

outermost :: middle _ function (); 
outermost : : middle _ secr * et _ function (); 
outermost :: inside : : inner _ function (); 
outermost :: inside : : secret _ function (); 

} 

リスト 7-6: 公開と非公開関数の例。不正なものもあります 

このコードをコンパイルする前に、 try_me 関数のどの行がエラーになるか当ててみてください。そ 
れからコンパイルを試して、合ってたかどうか確かめ、エラーの議論を求めて読み進めてください！ 
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7.2.3. 1 エラー を確かめる 

try _ me 関数は、プロジェクトのルートモジュールに存在しています。 outermost という名前のモ 
ジュールは非公開ですが、プライバシー規則の2番目にある通り、 try _ me のように、 outermost は現 
在（ルート）のモジュールなので、 try _ me 関数は、 outermost モジュールにアクセスすることを許可さ 
れるのです。 

middle _ function は公開なので、 outermost : : middle _ function という呼び出しも動作し、 try_me 
は middle _ function にその親モジュールの outermost を通してアクセスしています。このモジュー 
ルは、アクセス可能と既に決定しました。 

outermost : : mi ddle_sec ret_f uncti on の呼び出しは、コンパイルエラーになるでしよ 
う。 middle _ secret _ function は非公開なので、2番目の規則が適用されます。ルートモ 
ジュールは 、 mi ddle_sec ret_f uncti on の現在のモジュール ( outermost がそうです）でも、 
middle _ secret _ function の現在のモジュールの子供でもないのです。 

inside という名前のモジュールは非公開で子モジュールを持たないので、現在のモジュールである 
outermost からのみアクセスできます。つまり、 try _ me 関数は、 outermost : : inside : : inner_function 
も outermost : : inside : : secret _ function も呼び出すことを許されないのです。 

7.2.3.2 エラー を修正す る 

エラーを修正しようとする過程でできるコード変更案は、以下の通りです。各々試してみる前に、 
エラーを解消できるか当ててみてください。それからコンパイルして正しかったか間違っていたか確 
かめ、プライバシー規則を使用して理由を理解してください。もっと実験を企てて試してみるのもご 
自由に！ 

• inside モジュールが公開だったらどうだろうか？ 

• outermost が公開で、 i _ nside が非公開ならどうだろうか？ 

• i nner_functi on の本体で：： outermost : : middte _ sec 「 et _ function () を呼び出したらどうだろ 
うか？（頭の 二つの コロンは、 ルートモジュールから初めてモジュールを参照したいというこ 
とを意味します） 

今度は、 use キーワードで要素をスコープに導入する話をしましょう。 

7.3 異なるモジュールの名前を参照する 

モジュール名を呼び出しの一部に使用して、モジュール内に定義された関数の呼び出し方法を講義 
しました。リスト 7-7 に示した nested _ modules 関数の呼び出しのような感じですね。 

フアイル名： src / main.rs 


pub mod a { 
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pub mod senes { 
pub mod of { 

pub fn nested _ modules () {} 



} 

fn main() { 

a::series::of::nested_modules(); 

} 

リスト 7-7: 囲まれたモジュールをフルパス指定して関数を呼び出す 

見てお分かりの通り、 フルパス 指定した名前を参照すると非常に長ったらしくなります。幸い、 
Rust には、これらの呼び出しをもっと簡潔にするキーワードが用意されています。 

7.3.1 use キーワードで名前をスコープに導入する 

Rust の use キーワードは、呼び出したい関数のモジュールを スコープに 導入することで、長った 
らしい関数呼び出しを短縮します。以下は、 a : : series: :of モジュールをパイナリクレートのルート 
スコープに 持って く る例です： 

Filename: src/mam.rs 


pub mod a { 

pub mod series { 
pub mod of { 

pub fn nested _ modules () {} 



} 

use a :: series : : of ; 

fn main () { 

of : : nested _ modules (); 

} 


use a : : series : :of ; の行は、 of モジュールを参照したい箇所全部でフルパスの a : : series : : of を 
使用するのではなく、 of を利用できることを意味しています。 

この use キーワードは、指定したものだけをスコープに入れます：モジュールの子供はスコー 
プに導入しないのです。そのため、 nested_modules 関数を呼び出したい際に、それでもまだ of : : 
nested_modules を使わなければならないのです。 

以下のように、代わりに use で関数を指定して、関数をスコープに入れることもできました： 


pub mod a { 
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pub mod senes { 
pub mod of { 

pub fn nested_modules() {} 



use a: : series :: of: : nested_modules; 

fn main() { 

nested_modules(); 

} 


そうすれば、 モジュールを すべて取り除き、関数を直接参照する ことができます。 
enum も モジュール のようにある種の名前空間を なすので、 enum の列挙子を use で スコープに 
導入する こと もで きます。どんな use 文に関しても、一つの名前空間から複数の要素を スコープに 導 
入する場合、波 かっこと お尻にカンマを使用する ことで 列挙で きます。こんな 感じで： 


enum TrafficLight { 

Red , 

Yellow, 

Green , 

} 

use TrafficLight :: { Red , YeL low} ; 

fn main () { 

let red = Red ; 

let yellow = Yellow ; 

let green = TraftncLight : : Green ; 

} 

Green を use 文に含んでいないので、まだ Green バリアント用に TrafficLight 名前空間を指定し 
ています。 

7.3.2 Glob で全ての名前をスコープに導入する 

ある名前空間の要素を全て一度にスコープに導入するには、 * 表記が使用でき、これは glob (塊） 演 
算子と呼ばれます。この例は、ある enum の列挙子を各々を列挙せずに全てスコープに導入してい 
ます： 

enum TrafficLight { 

Red , 

Yellow, 

Green , 

} 


use TrafTi cli ght : ; 
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fn mann () { 

let red = Red ; 
let yellow = Yellow ; 
let green = Green ; 

} 

* 演算子は TrafficLight 名前空間に存在する全て公開要素をスコープに導入します。あまり glob 
は使用するべきではありません：便利ではありますが、 glob は予想以上の要素を引き込んで、名前衝 
突を引き起こす可能性があるのです。 

7.3.3 super を使用して親モジュールにアクセスする 

この章の頭で見かけたように、ライブラリクレートを作成する際、 Cargo は tests モジュールを用 
意してくれました。今からそれについて詳しく掘り下げていくことにしましょう。 communicator プロ 
ジェクトで src / lib.rs を開いてください： 

ファイル名： src/lib.rs 

pub mod client ; 

pub mod network ; 


#[ cfg ( test )] 
mod tests { 

#[ test ] 

fn it _ works () { 

assert _ eq ! (2 +2， 4); 



第 li 章でテストについて詳しく説明しますが、これでこの例の一部が持つ意味がわかったのでは 
ないでしょうか：他のモジュールに隣接する tests という名前のモジュールがあり、このモジュール 
は it_works という名前の関数を含んでいます。特別な注釈があるものの、 tests モジュールもただの 
モジュールです！よって、モジュール階層は以下のような見た目になります： 

commumcator 

I - client 

I - network 

| 1 - client 

1 - tests 

テストは、ライブラリ内でコードの準備運動を行うためのものなので、この Hworks 関数から 
client : : connect 関数を呼び出してみましょう。まあ、尤（もっと）も今のところ、機能の検査は何も 
しないんですけどね。これはまだ動きません： 
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ファイル名： src/lib.rs 

[ cfg ( test )] 
mod tests { 

#[ test ] 

fn it _ works () { 

client :: connect (); 



cargo test コマンドを呼び出してテストを実行してください: 


$ cargo test 

Compiling communicator * v 0.1.0 (rn ie :/// projects / commumcator ) 

error [ E 0433]: failed to resolve . Use of undeclared type or module ' client ' 

(エラー： 解決に失敗しました。未定義の型、またはモジ ュー ル ' client ' を使用していま 
す） 

-- > src / lib . rs :9:9 

I 

9 | client : : connectu ; 

| aaaaaa use of undeclared type or module ' client ' 

コンパイルが失敗しましたが、なぜでしょうか？ src / main . rs のように、関数の直前に 
communicator :: を配置する必要はありません。なぜなら、間違いなくここでは、 communicator * ライ 
ブラリクレート内にいるからです。原因は、パスが常に現在のモジュールに対して相対的になり、こ 
こでは tests になっているからです。唯一の例外は、 use 文内であり、パスは標準でクレートのルー 
卜に相対的になります。 tests モジュールは、 client モジュールがスコープに存在する必要があるの 
です！ 

では、どうやってモジュール階層を一つ上がり、 tests モジュールの client : : connect 関数を呼び 
出すのでしようか？ tests モジュールにおいて、先頭にコロンを使用して、コンパイラにルートから 
始めて、フルパスを列挙したいと知らせることもできます。こんな感じで： 

:: client : : connect () ; 

あるいは、 super を使用して現在のモジュールからモジュール階層を一つ上がることもできます。 
以下のように： 

super : : client : : connect () ; 

この例では、これら二つの選択はそれほど異なるようには見えませんが、モジュール階層がもっと 
深ければ、常にルートから書き始めるのは、コードを長ったらしくする原因になります。そのような 
場合、 super を使用して現在のモジュールから兄弟のモジュールに迪り着くのは、いいショートカッ 
卜になります。さらに、コードのいろんなところでルートからパスを指定してから、サブ木構造を別 
の箇所に移してモジュール構造を変化させた場合、複数箇所でパスを更新する必要に陥り、面倒なこ 
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とになるでしょう。 

各テストで super:: と入力しなければならないのも不快なことですが、それを解決してくれる道具 
をもう見かけています： use です！ super: :の機能は、 use に与えるパスを変更するので、 ルー トモ 
ジ ユールでは なく、親モジ ユー ルに対して相対的になります。 

このような理由から、ことに tests モジユールにおいて use super : : somthi ng は通常、最善策にな 
るわけです。故に、今ではテストはこんな見た目になりました： 

ファイル名： src / lib.rs 

^ [cfg(test)] 
mod tests { 

use super: : client; 

#[test] 

fn it_works() { 

client :: connect(); 

} 

} 

再度 cargo test を実行すると、テストは通り、テスト結果出力の最初の部分は以下のようになる 
でしょう： 

$ cargo test 

Compiling communicator* v0.1.0 (rn ie:///projects/commumcator) 

Running target/debug/communicator- 92007 ddb5330fa5a 


running 1 test 

test tests :: it_works ... ok 

test result : ok.1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out 


7.4 まとめ 

これでコードを体系化する新しいテクニックを知りましたね！これらのテクニックを使用して、関 
連のある機能をまとめ上げ、ファイルが長くなりすぎるのを防ぎ、ライブラリの使用者に整理整頓さ 
れた公開 API を提供してください。 

次は、自分の素晴らしく綺麗なコードで使用できる標準ライブラリのコレクションデータ構造につ 
いて見ていきましよう。 



一般的なコレクション 


Rust の標準ライブラリは、コレクションと呼ばれる多くの非常に有益なデータ構造を含んでいま 
す。他の多くのデータ型は、ある一つの値を表しますが、コレクションは複数の値を含むことができ 
ます。組み込みの配列とタプル型とは異なり、これらのコレクションが指すデータはヒープに確保さ 
れ、データ量はコンパイル時にわかる必要はなく、プログラムの実行にあわせて、伸縮可能であるこ 
とになります。各種のコレクションには異なる能力とコストが存在し、自分の現在の状況に最適なも 
のを選び取るスキルは、時間とともに育っていきます。この章では、 Rust のプログラムにおいて、非 
常に頻繁に使用される3つのコレクションについて議論しましょう。 

• ベクタ型は、可変長の値を並べて保持できる。 

• 文字列は、文字の コレクション である。以前、 String 型に ついて 触れたが、この章ではより掘 
り下げていく。 

•ハッシュマップは、値を特定のキーと紐付けさせてくれる。より一般的なデータ構造である、 
マップの特定の実装である。 

標準ライブラリで提供されている他の種のコレクションについて学ぶには、ドキュメントを参照さ 
れたし。 

ベクタ型、文字列、ハッシュマップの生成と更新方法や、各々が特別な点について議論していきま 
しょう。 

8.1 ベクタで一連の値を保持する 

最初に見るコレクションは、 Vec < T > であり、ベクタとしても知られています。ベクタは、メモリ上 
に値を隣り合わせに並べる単独のデータ構造に2つ以上の値を保持させてくれます。ベクタには、同 
じ型の値しか保持できません。要素のリストがある場合に有用です。例えば、テキストファイルの各 
行とか、ショッピングカートのアイテムの価格などです。 
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8.1.1 新しいベクタを生成する 

新しい空のベクタを作るには、リスト 8-1 に示されたように、 v ec :: ne w 関数を呼べばよいです。 
let v : Vec < i 32> = Vec :: new () ; 

リスト 8-1： 新しい空のベクタを生成して132型の値を保持する 

ここでは、型注釈を付け足したことに注目してください。このべクタに対して、何も値を挿入して 
いないので、コンパイラには、どんなデータを保持させるつもりなのかわからないのです。これは重 
要な点です。ベクタは、ジェネリクスを使用して実装されているのです；独自の型でジヱネリクスを使 
用する方法については、第 10 章で解説します。今は、標準ライブラリにより提供されている Vec < T > 
型は、どんな型でも保持でき、特定のベクタが特定の型を保持するとき、その型は山かっこ内に指定 
されることを知っておいてください。リスト 8-1 では、コンパイラに v の Vec < T > は、 i 32 型の要素 
を保持すると指示しました。 

より現実的なコードでは、一旦値を挿入したら、コンパイラは保持させたい値の型をしばしば推論 
できるので、この型注釈をすることは滅多にありません。初期値のある Vec < T > を生成する方が一般 
的ですし、 Rust には、利便性のために vec ! というマクロも用意されています。このマクロは、与 
えた値を保持する新しいベクタ型を生成します。リスト 8-2 では、1、2、3という値を持つ新しい 
Vec < i 32> を生成しています。 

let v = vec ! [1 ， 2, 3] ; 


リスト 8-2: 値を含む新しいベクタを生成する 


初期値の i 32 値を与えたので、コンパイラは、 v の型が Vec < i 32> であると推論でき、型注釈は必要 
なくなりました。次は、ベクタを変更する方法を見ましょう。 


8.1.2 ベクタを更新する 

ベクタを生成し、それから要素を追加するには、リスト 8-3 に示したように、 push メソッドを使用 
できます。 


let mut v = Vec :: new () ; 

v . push (5) : 
v . push (6) : 
v . push (7) ; 
v . push (8); 


リスト 8-3: push メソッドを使用してベクタ型に値を追加する 
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あらゆる変数同様、第3章で議論したように、値を変化させたかったら、 mut キーワードで可変に 
する必要があります。中に配置する数値は全て i 32 型であり、 コンパイラ はこのことをデータから推 
論するので、 Vec < i 32> という注釈は必要なくなります。 

8.1.3 ベクタをドロップすれば、要素もドロップする 

他のあらゆる構造体同様、ベクタもスコープを抜ければ、解放されます。リスト 8-4 に注釈したよ 
うにですね。 

{ 

let v = vec ! [1, 2， 3， 4]; 


// v で作業をする 


} // <- v はここでスコープを抜け、解放される 

リスト 8-4: ベクタとその要素がドロップされる箇所を示す 

ベクタがドロップされると、その中身もドロップされます。つまり、保持されていた整数値が、片付 
けられるということです。これは一見単純な点に見えるかもしれませんが、ベクタの要素への参照を 
導入した途端、もうちょっと複雑になる可能性を秘めています。次は、それに挑んでいきましょう！ 

8.1.4 ベクタの要素を読む 

もうべクタを生成し、更新し、破壊する方法を知ったので、中身を読む方法を知るのはいいステッ 
プアップです。ベクタに保持された値を参照する方法は2つあります。例では、さらなる明瞭性を求 
めて、これらの関数から返る値の型を注釈しました。 

リスト 8-5 に示したのは、両メソッドがベクタの値に対して、添字記法と get メソッドによりアク 
セスするところです。 

let v 二 vec ! [1 , 2， 3， 4, 5] ; 

let third : & i 32 = & v [2]; 

let third : 0 ption <& i 32> = v . get (2); 

リスト 8-5： 添字記法か get メソッドを使用してベクタの要素にアクセスする 

ここでは、 2 つのことに気付いてください。まず、 3 畨目の要素を得るのに 2 という添え字の値を 
使用していることです：ベクタは、数値により順序付けされ、添え字は0から始まります。2番目に、 
3 番目の要素を得る 2 つの方法は、&と [] を使用して参照を得るものと、番号を引数として get メ 
ソッドに渡して、 Option <& T > を得るものということです。 

Rust には要素を参照する方法が 2 通りあるので、ベクタに要素が含まれない番号の値を使用しよ 
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うとした時に、プログラムの振る舞いを選択できます。例として、ベクタに 5 つ要素があり、添え字 
100の要素にアクセスを試みた場合、プログラムがすることを確認しましょう。リスト 8-6 に示した 
ようにですね。 

let v = vec ! [1 , 2, 3， 4， 5]; 

let does _ not _ ex]st = & v [100」； 

let does _ not_exist = v . get (100) ; 

リスト 8-6: 5 つの要素を含むベクタの添え字100の要素にアクセスしようとする 

このコードを走らせると、最初の□メソッドはプログラムをパニックさせます。存在しない要素 
を参照しているからです。このメソッドは、ベクタの終端を超えて要素にアクセスしようとした時に 
プログラムをクラッシュさせたい場合に最適です。 

get メソッドがベクタ外の添え字を渡されると、パニックすることなく None を返します。普通の状 
態でも、ベクタの範囲外にアクセスする可能性がある場合に、このメソッドを使用することになるで 
しよう。そうしたら、コードには Some (& element ) か None を扱うロジックが存在することになりま 
す。そう、第6章で議論したように。例えば、添え字は人間に数値を入力してもらうことで得ること 
もできます。もし大きすぎる値を誤って入力し、プログラムが None 値を得てしまったら、現在べク 
夕に幾つ要素があるかをユーザに教え、再度正しい値を入力してもらうことができるでしょう。その 
方が、タイプミスでプログラムをクラッシュさせるより、ユーザに優しくなるでしょう。 

プログラム に有効な参照がある場合、借用チヱッ カー ( borrowchecker ) は （第 4 章で解説しまし 
たが)、所有権と借用規則を強制し、ベクタの中身へのこの参照や他のいかなる参照も有効であり続け 
ることを保証してくれます。同ー スコープ 上では、可変と不変な参照を同時には存在させられないと 
いう ルールを 思い出してください。この ルールはリスト 8-7 にも適用され、 リスト 8-7 ではべクタの 
最初の要素への不変参照を保持し、終端に要素を追加しようとしていますが、動きません。 

let mut v = vec ! [1, 2， 3， 4, 5] ; 

let first = & v [0]; 

v . push (6); 

リスト 8-7: 要素への参照を保持しつつ、ベクタに要素を追加しようとする 

この コー ドを コンパイル すると、こんな エラーに なります： 

error [ E 0502] : cannot borrow v as mutable because it is also borrowed as 
immutable 

(エラー： 不変としても借用されているので、 ' v ' を可変で借用できません） 

I 

4 | let first = & v [0] ; 

I - immutable borrow occurs here 
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5 

6 


( 不変借用はここで発生しています） 


v . push (6) ; 

a mutable borrow occurs here 


( 可変借用は、ここで発生しています） 


immutable borrow ends here 

( 不変借用はここで終了しています） 


リスト 8-7 のコードは、一見動くはずのように見えるかもしれません：なぜ、最初の要素への参照 
が、ベクタの終端への変更を気にかける必要があるのでしょうか？このエラーは、ベクタの動作法の 
せいです：新規要素をベクタの終端に追加すると、ベクタが現在存在する位置に隣り合って要素を入 
れるだけの領域がなかった場合に、メモリの新規確保をして古い要素を新しい スペースに コピーする 
必要があるかもしれないからです。その場合、最初の要素を指す参照は、解放されたメモリを指すこ 
とになるでしょう。借用規則により、そのような場面に陥らないよう回避されるのです。 

注釈： vec < T > の実装に関する詳細については、 https :// doc . rust - lang . org / stable / nomi - 
con / vec.html の、 ’’The Rustonomicon ” を参照されたし。 


8.1.5 ベクタの値を走査する 

ベクタの要素に順番にアクセスしたいなら、添え字で1回に1要素にアクセスするのではなく、全 
要素を走査することができます。リスト 8-8 で for ループを使い、132のべクタの各要素に対する不 
変な参照を得て、それらを出力する方法を示しています。 

let v 二 vec ! [100, 32， 57] ; 
for 1 in &v i 

println ! ("{}", i ); 

} 

リスト 8-8： for ループで 要素を走査し、ベクタの各要素を出力する 

全要素に変更を加える目的で、可変なベクタの各要素への可変な参照を走査することもできます。 
リスト 8-9 の for ループでは、各要素に50を足しています。 

let mut v = vec ! [100， 32， 57] ; 
for iin &mut v { 

*i += 50; 

} 

リスト 8-9: ベクタの要素への可変な参照を走査する 

可変参照が参照している値を変更するには、+=演算子を使用する前に、参照外し演算子 （*) を使用 
して i の値に迪り着かないといけません。 
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8.1.6 Enum を使って複数の型を保持する 

この章の冒頭で、ベクタは同じ型の値しか保持できないと述べました。これは不便なこともありま 
す；異なる型の要素を保持する必要性が出てくるユースケースも確かにあるわけです。幸運なことに、 
enum の列挙子は、同じ enum の型の元に定義されるので、ベクタに異なる型の要素を保持する必 
要が出たら、 enum を定義して使用することができます！ 

例えば、スプレッドシートの行から値を得たくなったとしましょう。ここで行の列には、整数を含 
むものや、浮動小数点数を含むもの、文字列を含むものがあります。列挙子が異なる値の型を保持す 
る enum を定義できます。そして、この enum の列挙子は全て同じ型： enum の型と考えられるわ 
けです。それからその enum を保持するべクタを生成でき、結果的に異なる型を保持できるようにな 
るわけです。リスト 8-10 でこれを模擬しています。 

enum SpreadsheetCell { 

Int ( i 32) ， 

Float ( f 64) , 

Text ( String ) , 

} 

let row = vec ![ 

SpreadsheetCell : : Int (3), 

SpreadsheetCell : : Text ( String : : f rom (" blue ") ), 

SpreadsheetCell : : Float (10.12), 

]； 


リスト 8-10： enum を定義して、一つのベクタに異なる型の値を保持する 

各要素を格納するのにヒープ上でズバリどれくらいのメモリが必要になるかをわかるように、 コン 
パイ ラが コンパイル 時にベクタに入る型を知る必要があります。副次的な利点は、このべクタではど 
んな型が許容されるのか明示できることです。もし Rust でべクタがどんな型でも保持できたら、ベ 
クタの要素に対して行われる処理に対して一つ以上の型がエラーを引き起こす可能性があったでしよ 
う。 enum に加えて match 式を使うことは、第 6 章で議論した通り、 コンパイル 時にありうる場合全 
てに対処していることを コンパイ ラが、保証できることを意味します。 

プログラム記述時にプログラムがべクタに実行時に保持するありとあらゆる一連の型をプログラマ 
が知らない場合、この enum テクニックはうまく動かないでしよう。代わりにトレイトオブジェクト 
を使用することができ、こちらは第17章で講義します。 

今や、ベクタを使用するべき最も一般的な方法について触れ、議論したので、標準ライブラリで 
vec < T > に定義されている多くの有益なメソッドについては、 API ドキュメントを確認することを心得 
てください。例として、 push に加えて 、 pop メソッドは最後の要素を削除して返します。次のコレク 
シヨン型に移りましよう： String です！ 
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8.2 文字列で UTF -8 でエンコードされたテキストを保持する 

第 4 章で文字列について語りましたが、今度はより掘り下げていきましょう。新参者の Rustacean 
は、 3 つの概念の組み合わせにより、文字列でよく行き詰まります： Rust のありうるエラーを晒す性 
質、多くのプログラマが思っている以上に文字列が複雑なデータ構造であること、そして UTF-8 で 
す。これらの要因が、他のプログラミング言語から移ってきた場合、一見困難に見えるように絡み合 
うわけです。 

コレクションの文脈で文字列を議論することは、有用なことです。なぜなら、文字列はテキストと 
して解釈された時に有用になる機能を提供するメソッドと、バイトの塊で実装されているからです。 
この節では、生成、更新、読み込みのような全コレクションが持つ String の処理について語ります。 
また、 String が他のコレクションと異なる点についても議論します。具体的には、人間とコンピュー 
夕が String データを解釈する方法の差異により、 String に添え字アクセスする方法がどう複雑なの 
かということです。 

8.2.1 文字列とは？ 

まずは、文字列という用語の意味を定義しましょう。 Rust には、言語の核として 1 種類しか文字列 
型が存在しません。文字列スライスの str で、通常借用された形態 &str で見かけます。第 4 章で、文 
字列スライスについて語りました。これは、別の場所に格納された UTF-8 エンコード された文字列 
データへの参照です。例えば、文字列リテラルは、プログラムのバイナリ出力に格納されるので、文 
字列スライスになります。 

String 型は、言語の核として組み込まれるのではなく、 Rust の標準ライブラリで提供されますが、 
伸長可能、可変、所有権のある UTF-8 エンコードされた文字列型です。 Rustacean が Rust におい 
て「文字列」を指したら、どちらかではなく、 String と文字列スライスの & str のことを通常意味し 
ます。この節は、大方、 String についてですが、どちらの型も Rust の標準ライブラリで重宝されて 
おり、どちらも UTF-8 エンコードされています。 

また、 Rust の標準ライブラリには、他の文字列型も含まれています。 OsString 、 OsStr 、 CString 
、 CStr などです。ライブラリクレートにより、文字列データを格納する選択肢はさらに増えます。そ 
れらの名前が全て String か Str で終わっているのがわかりますか？所有権ありと借用されたバー 
ジョンを指しているのです。ちょうど以前見かけた String と & str のようですね。例えば、これらの 
文字列型は、異なるエンコード方法でテキストを格納していたり、メモリ上の表現が異なったりしま 
す。この章では、これらの他の種類の文字列については議論しません；使用方法やどれが最適かにつ 
いては、 API ドキュメントを参照してください。 



第 8 章一般的な コレクション 


149 


8.2.2 新規文字列を生成する 

Vec<T> で使用可能な処理の多くが String でも使用できます。文字列を生成する new 関数から始め 
ましょうか。リスト 8-11 に示したようにですね。 

let mut s = Stn ng: : new(); 

リスト 8-11 ： 新しい空の String を生成する 

この行は、新しい空の s という文字列を生成しています。それからここにデータを読み込むことが 
できるわけです。だいたい、文字列の初期値を決めるデータがあるでしょう。そのために、 to.string 
メソッドを使用します。このメソッドは、文字列リテラルのように、 Display トレイトを実装する型 
ならなんでも使用できます。リスト 8-12 に2例、示しています。 

let data = "initial contents" ; 

let s = data.to_string(); 

// the method also works on a literal directly: 
let s = "initial contents" .to_string(); 

リスト 8-12 ： to_string メソッドを使用して文字列リテラルから String を生成する 

このコードは、 initial contents (初期値）を含む文字列を生成します 0 

さらに、 String: : from 関数を使っても、文字列リテラルから String を生成することができます。 
リスト 8-13 のコー ドは、 to_string を使用するリスト 8-12 のコード と等価です。 

let s = String: : from("i mtiaL contents") ; 

リスト 8-13： String:: from 関数を使って文字列リテラルから String を作る 

文字列は、非常に多くのものに使用されるので、多くの異なる一般的な API を使用でき、たく 
さんの選択肢があるわけです。冗長に思われるものもありますが、適材適所です！今回の場合、 
String: : from と to_string は全く同じことをします。従って、どちらを選ぶかは、スタイル次第です。 

文字列は UTF -8 エンコードされていることを覚えていますか？要するに文字列には、適切にエン 
コードされていればどんなものでも含めます。リスト 8-14 に示したように。 

let hello = String: : from ( n 产 ^ LJI joS-ic."); 
let hello = String: : from("Dobry den") ; 
let hello = Stri ng: : from ("Hello") ; 
let hello = String: :from (’’□ けヂ ） ; 
let hello = String: : f rom("^RT^ M ); 
let hello = String: : from( n こんにち は 11 ); 
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let hello = String : : f 司■ス 11> R n ) ; 
let hello = String : : from ("你 好 11 ); 
let hello = String : : from("01a") ; 
let hello = String : : f rom( n 3flpaBCTBynTe n ) ; 
let hello = String : : from( n Hola n ) ; 

リスト 8-14: いろんな言語の挨拶を文字列に保持する 
これらは全て、有効な String の値です。 

8.2.3 文字列を更新する 

String は、サイズを伸ばすことができ、 Vec < T > の中身のように、追加のデータをプッシュすれば、 
中身も変化します。付け加えると、51「1叩値を連結する+演算子や、 format ! マクロを便利に使用す 
ることができます。 

8.2.3.1push_str と push で文字列に追加する 

push_str メソッドで文字列スライスを追記することで、 String を伸ばすことができます。リスト 
8-15 の通りです。 

let mut s = String : : rrom("Too") ; 
s. push_str("bar") : 

リスト 8-15： push_str メソッドで String に文字列スライスを追記する 

この2行の後、 s は foobar を含むことになります。 push_str メソッドは、必ずしも引数の所有権 
を得なくていいので、文字列スライスを取ります。例えば、リスト 8-16 のコードは、中身を si に追 
加した後、 s 2 を使えなかったら残念だということを示しています。 

let mut si = Stri ng : : from (" too ") ; 
let s 2 = " bar " ; 
si . push _ str ( s 2); 
pr - intln ! ( M s 2 is {}，'， s 2); 

リスト 8-16： 中身を String に追加した後に、文字列スライスを使用する 

もし、 push _ str ■メソッドが S 2 の所有権を奪っていたら、最後の行でその値を出力することは不可 
能でしょう。ところが、このコードは予想通りに動きます！ 

push メソッドは、1文字を引数として取り、 String に追加します。リスト 8-15 は 、 push メソッド 
で1を String に追加するコードを呈示しています。 

let mut s = Stn ng : : rrom (" lo ") ; 
s • push ('1'); 
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リスト 8-17： push で String 値に1文字を追加する 

このコードの結果、 s はを含むことになるでしよう。 

編者注： 10 1は laughing out loud (大笑いする）の頭文字からできたスラングです。日本語の 
WWW みたいなものですね。 


8 . 23.2 +演算子、または format ! マクロで連結 

2つのすでにある文字列を組み合わせたくなることがよくあります。リスト 8-18 に示したように、 
一つ目の方法は、+演算子を使用することです。 

let si = String : : from ( M Hello ,") ; 

Let s 2 = Stn ng : : rrom( "world ! ") ; 

let s 3 = si + & s 2; // si はムーブされ、もう使用できないことに注意 

リスト 8-18： +演算子を使用して二つの String 値を新しい String 値にする 

このコードの結果、 S 3 という文字列は、 HelAo , world ! を含むことになるでしょう。追記の後 、 si 
がもう有効でなくなった理由と、 S 2 への参照を使用した理由は、+演算子を使用した時に呼ばれるメ 
ソッドのシグニチヤと関係があります。+演算子は 、 add メソッドを使用し、そのシグニチヤは以下 
のような感じです： 

fn add ( self , s : & str ) -> String { 

これは、標準ライブラリにあるシグニチヤそのものではありません：標準ライブラリでは、 add は 
ジェネリクスで定義されています。ここでは、ジェネリックな型を具体的な型に置き換えた add のシ 
グニチヤを見ており、これは、このメソッドを String 値とともに呼び出した時に起こることです。 
ジェネリクスについては、第10章で議論します。このシグニチヤが、+演算子の巧妙な部分を理解す 
るのに必要な手がかりになるのです。 

まず、 s 2 には&がついてます。つまり、 add 関数の s 引数のために最初の文字列に2番目の文字列 
の参照を追加するということです： String には & str を追加することしかできません。要するに2つ 
の String 値を追加することはできないのです。でも待ってください。 add の第2引数で指定されて 
いるように、 &S2 の型は、 & str ではなく、 & String ではないですか。では、なぜ、リスト 8-18 は、コ 
ンパイルできるのでしょうか？ 

add 呼び出しで & s 2 を使える理由は、コンパイラが & String 引数を & str に 型 強制してくれるためで 
す 。 add メソッド呼び出しの際、コンパイラは、参照 外し 型強制というものを使用し、ここでは、 & S 2 
を & S 2[..] に変えるものと考えることができます。参照外し型強制について詳しくは、第15章で議 
論します。 add が s 引数の所有権を奪わないので、この処理後も S 2 が有効な String になるわけです。 
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2番目に、シグニチャから add は self の所有権をもらうことがわかります。 self には&がついて 
いないからです。これはつまり、リスト 8-18 において si は add 呼び出しにムーブされ、その後は有 
効ではなくなるということです。故に、 S 3 = si + & S 2; は両文字列をコピーして新しいものを作るよ 
うに見えますが、この文は実際には si の所有権を奪い、 S 2 の中身のコピーを追記し、結果の所有権 
を返すのです。言い換えると、たくさんのコピーをしているように見えますが、違います；実装は、コ 
ピーよりも効率的です。 

複数の文字列を連結する必要が出ると、+演算子の振る舞いは扱いにくくなります： 

let si = String : : from ( n tic n ) ; 
let s 2 = String : : from (" tac ") ; 
let s 3 = String : : from (" toe ") ; 

let s = si + + & s 2 + + & s 3; 


ここで、 s は tic - tac-toe になるでしよう。 + と”文字のせいで何が起きているのかわかりにくい 
です。もっと複雑な文字列の連結には、 format ! マクロを使用することができます： 

let si = String : : from (" tic ") ; 
let s 2 = String : : from (" tac ") ; 
let s 3 = Stri ng : : from (" toe ") ; 

let s = format ! ("{}-{}-{}", si , s 2 ， s 3); 

このコードでも、 s は tic - tac-toe になります。 format ! マクロは、 println ! と同様の動作をしま 
すが、出力をスクリーンに行う代わりに、中身を String で返すのです。 format ! を使用したコードの 
方がはるかに読みやすく、引数の所有権を奪いません。 

8.2.4 文字列に添え字アクセスする 

他の多くのプログラミング言語では、文字列中の文字に、添え字で参照してアクセスすることは、 
有効なコードであり、一般的な処理です。しかしながら、 Rust において、添え字記法で String の一 
部にアクセスしようとすると、エラーが発生するでしょう。リスト 8-19 の非合法なコードを考えて 
ください。 

let si = String : : from (" hello ") ; 
let h = si [0]; 

リスト 8-19: 文字列に対して添え字記法を試みる 
このコードは、以下のようなエラーに落ち着きます： 


error [ E 0277] : the trait bound std :: string : : String : std :: ops :: Index <{ Integer }> 
is not satisfied 
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(エラー： トレイト境界、 std: :string: :String: std : : ops : : Index<{Integer}>' が満たされ 
ていません） 

1> 

3 | > let h = si [0] ; 

| > aaa ハ a the type std :: stnng::Stnng cannot be indexed by i 

Integer }' 

| > (型 ' std : : string : : String ' は、 { Integer }' で添え字アクセスでき 

ません） 

= help : the trait ' std :: ops :: Index <{ Integer }> is not imolemented for std :: 
string : : String ' 

(へ ノレプ： ' std : : ops : : Index <{ Integer }> 、というトレイトカ 5 '、 std : : string : : String ' に対 
して実装されていません） 

エラーと注釈が全てを物語っています： Rust の文字列は、添え字アクセスをサポートしていないの 
です。でも、なぜでしょうか？その疑問に答えるには、 Rust がメモリにどのように文字列を保持し 
ているかについて議論する必要があります。 

8.2.4. 1内部表現 

String は Vec<u8> のラッパです。リスト 8-14 から適切に UTF-8 でエンコードされた文字列の例 
をご覧くださぃ。まずは、これ： 

let len = String: : f rom( M Hola M ) ,len(); 

この場合、 len は 4 になり、これは、文字列” Hola” を保持するべクタの長さが4バイトであるこ 
とを意味します。これらの各文字は、 UTF-8 で エンコード すると、1バイトになるのです。しかし、 
以下の行ではどうでしょうか？（この文字列は大文字のキリル文字 Ze で始まり、アラビア数字の3 
では始まっていないことに注意してください） 

let len = String : : f rom("3flpaBCTBynTe") ,len() ; 

文字列の長さはと問われたら、あなたは12と答えるかもしれません。ところが、 Rust の答えは、 
24です：“ 3flpaBCTByfiTe” を UTF-8 で エンコード すると、この長さになります。各 Unicode スカ 
ラー 値は、2バイトの領域を取るからです。それ故に、文字列のバイトの添え字は、必ずしも有効な 
Unicode の スカラー 値とは相互に関係しないのです。 デモ 用に、こんな非合法な Rust コードを 考え 
てください： 

let heilo = "3flpaBCTBynTe" : 

let answer = & hello [0」； 

answer の値は何になるべきでしょうか？最初の文字の3になるべきでしょうか？ UTF-8 エンコー 
ドされた時、3の最初のバイトは208、2番目は151になるので、 answer は実際、208になるべきで 
すが、208は単独では有効な文字ではありません。この文字列の最初の文字を求めてぃる場合、208を 
返すことは、ユーザの望んでいるものではないでしょう；しかしながら、 Rust には、バイト添え字0 
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の位置には、そのデータしかないのです。文字列がラテン文字のみを含む場合でも、ユーザは一般的 
にバイト値が返ることを望みません： &" heUo "[0] がバイト値を返す有効なコードだったら、卜では 
なく、104を返すでしょう。予期しない値を返し、すぐには判明しないバグを引き起こさないために、 
Rust はこのコードを全くコンパイルせず、開発過程の早い段階で誤解を防いでくれるのです。 

8 . 2 A .2 バイトとスカラー値と書記素クラスタ！なんてこった！ 

UTF -8 について別の要点は、実際 Rust の観点から文字列を見るには 3 つの関連した方法があると 
いうことです：バイトとして、スカラー値として、そして、書記素クラスタ（人間が文字と呼ぶものに 
一番近い）としてです。 

ヒンディー語の単語、“不网尹”をデーヴァナーガリー（訳注：サンスクリット語とヒンディー語を書 
くときに使われる書記法）で表記したものを見たら、以下のような見た目の U 8 値のベクタとして保持 
されます： 

[224, 164, 168, 224, 164, 174, 224, 164, 184, 224, 165, 141, 224, 164, 164, 

224, 165, 135] 

18 バイトになり、このようにしてコンピュータは最終的にこのデータを保持しているわけです。こ 
れを Unicode スカラー値として見たら、 Rust の char 型はこれなのですが、このバイトは以下のよ 
うな見た目になります： 

[ w , ,'丑'， V ，'石'，ハ] 

ここでは、 6 つ Char 値がありますが、 4 番目と 6 番目は文字ではありません：単独では意味をなさ 
ないダイアクリティックです。最後に、書記素クラスタとして見たら、このヒンディー語の単語を作 
り上げる人間が 4 文字と呼ぶであろうものが得られます： 

" IT ", "丑"，"合"] 

Rust には、データが表す自然言語に関わらず、各プログラムが必要な解釈方法を選択できるよう 
に、コンピュータが保持する生の文字列データを解釈する方法がいろいろ用意されています。 

Rust で文字を得るのに String に添え字アクセスすることが許されない最後の理由は、添え字アク 
セスという処理が常に定数時間 (0(1)) になると期待されるからです。しかし 、 St ri ng でそのパフォー 
マンスを保証することはできません。というのも、合法な文字がいくつあるか決定するのに、最初か 
ら添え字まで中身を走査する必要があるからです。 

8.2.5 文字列をスライスする 


文字列に添え字アクセスするのは、しばしば悪い考えです。文字列添え字処理の戻り値の型が明瞭 
ではないからです：バイト値、文字、書記素クラスタ、あるいは文字列スライスにもなります。故に、 
文字列スライスを生成するのに、添え字を使う必要が本当に出た場合にコンパイラは、もっと特定す 
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るよう求めてきます。添え字アクセスを特定し、文字列スライスが欲しいと示唆するためには、□で 
1つの数値により添え字アクセスするのではなく、範囲とともに [] を使って、特定のバイトを含む文 
字列スライスを作ることができます： 

let he ilo = "3flpaBCTBvnTe" ; 

let s = &hello[0..4]; 


ここで、 s は文字列の最初の 4 バイトを含む & str になります 0 先ほど、これらの文字は各々2バイ 
卜になると指摘しましたから、 s は 3 fl になります。 

& heUo [ 0 .. 1 ] と使用したら、何が起きるでしょうか？答え： Rust はべクタの非合法な添え字にア 
クセスしたかのように、実行時にパニックするでしょう： 

thread ' mann ' panicked at ' bvte index 1 is not a char boundary; it is inside '3' 
(bytes 0..2) of '3flpaBCTBynTe'', src/libcore/str/mod.rs : 2188 : 4 
('main 1 スレッドは「バイト添え字 1 は文字の境界ではありません； ' 3flpaBCTByMTe' の 1 3 1 ( 

バイト番号 0 から 2) の中です」でパニックしました） 

範囲を使用して文字列スライスを作る際にはプログラムをクラッシュさせることがあるので、気を 
つけるべきです。 

8.2.6 文字列を走査するメソッド群 

幸いなことに、他の方法でも文字列の要素にアクセスすることができます。 

もし、個々の Unicode スカラー値に対して処理を行う必要があったら、最適な方法は chars メ 
ソッドを使用するものです。に対して chars を呼び出したら、分解して6つの char 型の値 
を返すので、各要素にアクセスするには、その結果を走査すればいいわけです： 

for c in "づ • chars () { 
println ! ("{}", c ) ; 

} 

このコードは、以下のように出力します： 


丑 


bytes メソッドは、各バイトをそのまま返すので、最適になることもあるかもしれません: 

for b in n 羽喷 ". bytes () { 
println ! ("{}", b ); 
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} 

このコードは、 String をなす18バイトを出力します： 

224 

164 

// -- snip -- 

165 
135 

ですが、合法な Unicode スカラー値は、2バイト以上からなる場合もあることは心得ておいてく 
ださい。 

書記素クラスタを文字列から得る方法は複雑なので、この機能は標準ライブラリでは提供されてい 
ません。この機能が必要なら、 crates . io でクレートを入手可能です。 

8.2.7 文字列はそう単純じゃない 

まとめると、文字列は込み入っています。プログラミング言語ごとにこの複雑性をプログラマに提 
示する方法は違います。 Rust では、 String データを正しく扱うことが、全ての Rust プログラムに 
とっての規定動作になっているわけであり、これは、プログラマが UTF -8 データを素直に扱う際に、 
より思考しないといけないことを意味します。このトレードオフにより、他のプログラミング言語で 
見えるよりも文字列の複雑性がより露出していますが、 ASCII 以外の文字に関するエラーを開発の後 
半で扱わなければならない可能性が排除されているのです。 

もう少し複雑でないものに切り替えていきましょう：ハッシュマップです！ 

8.3 ハッシュマップに値に紐づいたキーを格納する 

一般的なコレクションのトリを飾るのは、ハッシュマップです。型 HashMap < K , V > は、 K 型のキー 
と V 型の値の対応関係を保持します。これをハッシュ関数を介して行います。ハッシュ関数は、キー 
と値のメモリ配置方法を決めるものです。多くのプログラミング言語でもこの種のデータ構造はサ 
ポートされていますが、しばしば名前が違います。 hash 、 map 、 object 、 ハッシュテーブル、連想 
配列など、枚挙に暇（いとま）はありません。 

ハッシュ マップは、ベクタのように番号ではなく、どんな型にもなりうるキーを使ってデータを参 
照したいときに有用です。例えば、ゲームにおいて、各チームのスコアを ハッシュ マップで追いかけ 
ることができます。ここで、各キーはチーム名、値が各チームのスコアになります。チーム名が与え 
られれば、スコアを扱うことができるわけです。 

この節でハッシュマップの基礎的な API を見ていきますが、より多くのグッズが標準ライブラリに 
より、 HashMap < K , V > 上に定義された関数に隠されています。いつものように、もっと情報が欲しけ 
れば、標準ライブラリのドキュメントをチェックしてください。 
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8.3.1 新規ハッシュマップを生成する 

空のハッシュマップを new で作り、要素を insert で追加することができます。リスト 8-20 では、 
名前がブノレ^一とイェロ^一の2チ^ームのスコアを追いかけています。ブノレ^ー チ ームは10点から、イェ 
ローチームは50点から始まります。 

use std :: collections : : HashMap ; 

let mut scores = HashMap : : new (); 

scores . insert ( String : : f rom (" Blue ") ,10); 

scores . insert ( String : : from (" Yellow 11 ) ， 50); 

リスト 8-20: ハッシュマップを生成してキーと値を挿入する 

最初に標準ライブラリの コレクション 部分から HashMap を use する必要があることに注意してく 
ださい。今までの3つの一般的な コレクションの 内、これが最も使用頻度が低いので、初期化処理で 
自動的にスコープに導入される機能には含まれていません。また、標準ライブラリからのサポートも 
ハッシュマップは少ないです；例えば、生成するための組み込みマクロがありません。 

ベクタと全く同様に、ハッシュマップはデータをヒープに保持します。この HashMap はキーが 
String 型、値は i 32 型です。ベクタのように、ハッシュマップは均質です：キーは全て同じ型でなけ 
ればならず、値も全て同じ型でなければなりません。 

ハッシュマップを生成する別の方法は、タプルのベクタに対して collect メソッドを使用するもの 
です。ここで、各タプルは、キーと値から構成されています。 collect メソッドはいろんなコレクショ 
ン型にデータをまとめ上げ、そこには HashMap も含まれています。例として、チーム名と初期 スコア 
が別々のべクタに含まれていたら、 zip メソッドを使ってタプルのベクタを作り上げることができ、 
そこでは「ブルー」は10とペアになるなどします。リスト 8-21 に示したように、それから collect 
メソッドを使って、そのタブルのベクタをハッシュマップに変換することができるわけです。 

use std :: collections :: HashMap ; 

Let teams = vec ! [ String : : rrom (" Blue ") , String : : from (" Ye Llow ") ]; 

let initial_scores = vec ! [10, 50]; 

let scores : HashMap <_, _> = teams . iter (). zip ( initial _ scores . iter ()). collect (); 

リスト 8-21: チームのリストとスコアのリストから ハッシュ マップを作る 

ここでは、 HashMap <_, _>という型注釈が必要になります。なぜなら、いろんなデータ構造に 
まとめ上げる ことができ、コンパイラは指定しない限り、どれを所望なのかわからないからです。とこ 
ろが、キーと値の型引数については、アンダースコアを使用しており、コンパイラはベクタのデータ 
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型に基づいてハッシュマップが含む型を推論することができるのです。 

8.3.2 ハッシュマップと所有権 

i 32 のような Copy トレイトを実装する型について、値はハッシュマップにコピーされます。 String 
のような所有権のある値なら、値はムーブされ、リスト 8-22 でデモされているように、ハッシュマッ 
プはそれらの値の所有者になるでしょう。 

use std :: collections : : HashMap ; 

let rield_name = Stnng : : f rom( M Favon te color ") ; 
let field_value = String : : f rom (" Blue ") ; 

let mut map = HashMap : : new (); 
map . insert ( field _ name , field _ value ); 

// field_name and field_value are invalid at this point , try using them and 
// see what compiler error you get ! 

// field_name と field_value はこの時点で無効になる。試しに使ってみて 
// どんなコンパイルエラーが出るか確認してみて！ 

リスト 8-22: 一旦挿入されたら、キーと値はハッシュマップに所有されることを示す 

insert を呼び出して field _ name と field _ va 1 ue がハッシュマップにムーブされた後は、これらの 
変数を使用することは叶いません。 

値への参照を ハッシュマッ プに挿入したら、値は ハッシュマッ プにムーブされません。参照が指し 
ている値は、最低でも ハッシュ マップが有効な間は、有効でなければなりません。これらの問題につ 
いて詳細には、第10章の「ライフタイムで参照を有効化する」節で語ります。 

8.3.3 ハッシュマップの値にアクセスする 

リスト 8-23 に示したように、キーを get メソッドに提供することで、 ハッシュマッ プから値を取 
り出すことができます。 

use std : : collections :: HashMap ; 

let mut scores = HashMap : : new (); 

scores . insert ( String : : f rom (" Blue ") ,10); 
scores . insert ( String : : from (" Yellow ") , 50); 

let team_name = String : : from (" Blue ") ; 
let score = scores . get (& team _ name ); 


リスト 8-23: ハッシュマッ プに保持されたブルーチームのスコアにアクセスする 
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ここで、 score はブルーチームに紐づけられた値になり、結果は Some (&10) となるでしょう。結果 
は Some に包まれます。というのも、 get は Option く & V > を返すからです；キーに対応する値がハッシュ 
マップになかったら、 get は None を返すでしょう。プログラムは、この Option を第6章で講義した 
方法のどれかで扱う必要があるでしょう。 

ベクタのように、 for ループでハッシュマップのキーと値のペアを走査することができます： 

use std :: collections : : HashMap ; 

let mut scores = HashMap : : new (); 

scores . insert ( String : : f rom ( M Blue ") ,10); 
scores . insert ( String : : f rom (" Yellow ") , 50); 

for ( key , value ) in &scores { 

println ! ("{} : {}" , key , value ); 

} 

このコードは、各ペアを任意の順番で出力します： 

Yellow : 50 
Blue :10 


8.3.4 ハッシュマップを更新する 

キーと値の数は伸長可能なものの、各キーには1回に1つの値しか紐づけることができません。 
ハッシュマッ プ内のデータを変えたい時は、すでにキーに値が紐づいている場合の扱い方を決めなけ 
ればなりません。古い値を新しい値で置き換えて、古い値を完全に無視することもできます。古い値 
を保持して、新しい値を無視し、キーにまだ値がない場合に新しい値を追加するだけにすることもで 
きます。あるいは、古い値と新しい値を組み合わせることもできます。各方法について見ていきま 
しょう！ 

8.3.4. 1値を上書きする 

キーと値をハッシュマップに挿入し、同じキーを異なる値で挿入したら、そのキーに紐づけられて 
いる値は置換されます。リスト 8-24 のコードは、 insert を二度呼んでいるものの、ハッシュマップ 
には 一つの キーと値の組しか含まれません。なぜなら、ブルーチームキーに対する値を2回とも挿入 
しているからです。 

use std : : collections : : HashMap ; 

let mut scores = HashMap : : new (); 

scores . insert ( String : : f rom (" Blue ") ,10); 
scores . insert ( String : : from (" Blue 11 ) ， 25); 
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println ! ("{:?}", scores ) ; 

リスト 8-24: 特定のキーで保持された値を置き換える 

このコードは、 {" Blue ": 25} と出力するでしょう。10という元の値は上書きされたのです。 

8.3.4.2 キーに値がなかった時のみ値を揷入する 

特定のキーに値があるか確認することは一般的であり、存在しない時に値を挿入することも一般的 
です。ハッシュマップには、これを行う entry と呼ばれる特別な API があり、これは、引数として 
チェックしたいキーを取ります。この entry メソッドの戻り値は、 Entry と呼ばれる enum であり、 
これは存在したりしなかったりする可能性のある値を表します。イェローチームに対するキーに値が 
紐づけられているか否か確認したくなったとしましょう。存在しなかったら、 50 という値を挿入した 
く、ブルーチームに対しても同様です 。 entry API を使用すれば、コードはリスト 8-25 のようにな 
ります。 


use std :: collections : : HashMap ; 

let mut scores = HashMap: : new(); 
scores.insert (String: : f rom( M Blue") ,10); 

scores•entry (String: : f rom("Yellow") ).or_insert(50); 
scores•entry (String: : f rom("Blue") ).or_insert(50); 

println! ("{:?}", scores); 

リスト 8-25 ： entry メソッドを使ってキーに値がない場合だけ挿入する 

Entry 上の or_insert メソッドは、対応する Entry キーが存在した時にそのキーに対する値への可 
変参照を返すために定義されており、もしなかったら、引数をこのキーの新しい値として挿入し、新 
しい値への可変参照を返します。このテクニックの方が、そのロジックを自分で書くよりもはるかに 
綺麗な上に、 borrow checker とも親和性が高くなります。 

リスト 8-25 のコードを実行すると、 {"YeVLow": 50, "Blue":10} と出力するでしょう。最初の 
entry 呼び出しは、まだ イェローチームに 対する値がないので、値 50 で イェローチームの キーを揷 
入します。 entry の 2 回目の呼び出しはハッシュマップを変更しません。なぜなら、 ブルーチームに 
は既に10という値があるからです。 


8.3.4.3古い値に基づいて値を更新する 

ハッシュ マップの別の一般的なユースケースは、キーの値を探し、古い値に基づいてそれを更新す 
ることです。例えば、リスト 8-26 は、各単語があるテキストに何回出現するかを数え上げるコード 
を示しています。キーに単語を入れた ハッシュ マップを使用し、その単語を何回見かけたか追いかけ 
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るために値を増やします。ある単語を見かけたのが最初だったら、まず0という値を挿入します： 

use std :: collections: : HashMap; 

let text = "hello world wonderful world" ; 

let mut map = HashMap :: new(); 

for word in text.split_whitespace() { 

let count = map.entry(word).or_insert(0); 

★count +=1; 

} 

println! ("{:?}", map); 

リスト 8-26: 単語とカウントを保持するハッシュマップを使って単語の出現数をカウントする 

このコードは、 {"world": 2, "hello": 1, "wonderful":1} と出力するでしよう。 or_inser*t 関 
数は実際、このキーに対する値への可変参照 （&mut V ) を返すのです。ここでその可変参照を count 
変数に保持しているので、その値に代入するには、まずアスタリスク （*) で count を参照外ししなけ 
ればならないのです。この可変参照は、 for ループの終端でスコープを抜けるので、これらの変更は 
全て安全であり、借用規則により許可されるのです。 

8.3.5 ハッシュ関数 

標準では、 HashMap はサービス拒否 ( DoS ) アタック に対して抵抗を示す暗号学的に安全な ハッシュ 
関数を使用します。これは、利用可能な最速の ハッシュ アルゴリズムではありませんが、パフォーマ 
ンスの欠落と引き換えに安全性を得るというトレードオフは、価値があります。自分のコードをプロ 
ファイリングして、自分の目的では標準の ハッシュ 関数は遅すぎると判明したら、異なる hasher を 
指定することで別の関数に切り替えることができます。 hasher とは、 BuildHasher トレイトを実装 
する型のことです。トレイトに ついて とその実装方法に ついては、 第 10 章で語ります。必ずしも独 
自の hasher を1から作り上げる必要はありません； crates . io には、他の Rust ユーザによって共有 
された多くの一般的な ハッシュア ルゴリズムを実装した hasher を提供するライブラリがあります。 

8.4 まとめ 

ベクタ、文字列、ハッシュマップはデータを保持し、アクセスし、変更する必要のあるプログラム 
で必要になる、多くの機能を提供してくれるでしょう。今なら解決可能なはずの練習問題を用意しま 
した： 

•整数のリストが与えられ、ベクタを使って mean (平均値)、 median (ソートされた時に真ん中 
に来る値)、 mode (最も頻繁に出現する値； ハッシュマッ プがここでは有効活用できるでしょ 
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う）を返してください。 

• 文字列をピッグ•ラテン（訳注：英語の言葉遊びの一つ）に変換してください。各単語の最初の 
子音は、単語の終端に移り、” ay” が足されます。従って、” first” は” irst-fay” になります。た 
だし、母音で始まる単語には、お尻に” hay” が付け足されます（” apple” は” apple-hay” にな 
ります)。 UTF-8 エンコード に関する詳細を心に留めておいてください！ 

• ハッシュマップとベクタを使用して、 ユーザに 会社の部署に雇用者の名前を追加させられる 
テキストインターフェイスを作ってください。例えば、” Add Sally to Engineering” (開発部 
門にサリーを追加）や” Add Amir to Sales” (販売部門にアミールを追加）などです。それから 
ユーザに、 ある部署にいる人間の一覧や部署ごとに アルファべ ット順で並べ替えられた会社の 
全人間の一覧を扱わせてあげてください。 

標準ライブラリの API ドキュメントには、この練習問題に有用な、ベクタ、文字列、ハッシュマッ 
プのメソッドが解説されています。 

処理が失敗することもあるような、より複雑なプログラムに入り込んできています；ということは、 
エラーの 処理法について議論す るのに ぴったりということです。次はそれをします！ 



エラー 処理 


Rust の信頼性への傾倒は、エラー処理にも及びます。ソフトウェアにおいて、エラーは生きている 
証しです。従って、 Rust には何かがおかしくなる場面を扱う機能がたくさんあります。多くの場面 
で、コンパイラは、プログラマにエラーの可能性を知り、コードのコンパイルが通るまでに何かしら 
対応を行うことを要求してきます。この要求により、エラーを発見し、コードを実用に供する前に適 
切に対処していることを確認することでプログラムを頑健なものにしてくれるのです！ 

Rust では、エラーは大きく二つに分類されます：回復可能と回復不能なエラーです。ファイルが見 
つからないなどの回復可能なエラーには、問題をユーザに報告し、処理を再試行することが合理的に 
なります。回復不能なエラーは、常にバグの兆候です。例えば、配列の境界を超えた箇所にアクセス 
しようとすることなどです。 

多くの言語では、この2種のエラーを区別することはなく、例外などの機構を使用して同様に扱い 
ます。 Rust には例外が存在しません。代わりに、回復可能なエラーには Result < T ， E > 値があり、プ 
ログラムが回復不能なエラーに遭遇した時には、実行を中止する panic ! マクロがあります。この章 
では、まず panic ! の呼び出しを講義し、それから Result < T ， E > を戻り値にする話をします。加え 
て、エラーからの回復を試みるか、実行を中止するか決定する際に考慮すべき事項についても、探究 
しまし よつ。 


9.1 parH c !で回復不能なエラー 

時として、コードで悪いことが起きるものです。そして、それに対してできることは何もありませ 
ん。このような場面で、 Rust には panic ! マクロが用意されています。 panic !マクロが実行される 
と、プログラムは失敗のメッセージを表示し、スタックを巻き戻し掃除して、終了します。これが最 
もありふれて起こるのは、何らかのバグが検出された時であり、プログラマには、どうエラーを処理 
すればいいか明確ではありません。 
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9.1.1 パニックに対してスタックを巻き戻すか異常終了するか 

標準では、パニックが発生すると、プログラムは巻き戻しを始めます。つまり、言語がスタック 
を遡り、遭遇した各関数のデータを片付けるということです。しかし、この遡りと片付けはす 
べきことが多くなります。対立案は、即座に異常終了し、片付けをせずにプログラムを終了さ 
せることです。そうなると、プログラムが使用していたメモリは、 0 S が片付ける必要がありま 
す。プロジェクトにおいて、実行可能ファイルを極力小さくする必要があれば、 Cargo , toml 
ファイルの適切な [ profile ] 欄に panic = ' abort ' を追記することで、パニック時に巻き民 
しから異常終了するように切り替えることができます。例として、リリースモード時に異常終 
了するようにしたければ、以下を追記してください： 

[pron le . release ] 
panic = ' abort ' 


単純なプログラムで panic ! の呼び出しを試してみましょう： 

フアイル名： src/main.rs 
fn main () { 

pani c ! ("crash and burn ") ; // クラッ シユ して炎上 

} 

このプログラムを実行すると、以下のような出力を目の当たりにするでしょう： 

5 cargo run 

Compiung panic v 0. 1 .0 (ti Le : /// pro ] ects / pamc ) 

Finished dev [unoptimized + debuginfo ] target ( s ) in 0.25 secs 
Running ' target / debug / panic ' 

thread , main , panicked at 'crash and burn ', src / main . rs :2:4 

(' main ' スレッドは src/mai n . rs :2:4 の「クラッ シユ して炎上」でパニックしました） 
note : Run with 'RUST BACKTRACE = l ' for a backtrace . 


panic ! の呼び出しが、最後の 2 行に含まれるエラーメッセージを発生させているのです。 1 行目にパ 
ニックメッセージと ソース コード中でパニックが発生した箇所を示唆しています： src / main . rs :2:4 
は、 src / main . rs ファイルの2行目4文字目であることを示しています。 

この場合、示唆される行は、自分のコードの一部で、その箇所を見に行けば、 panic ! マクロ呼び出 
しがあるわけです。それ以外では、 panic ! 呼び出しが、自分のコードが呼び出しているコードの一 
部になっている可能性もあるわけです。 エラー メッセージで報告されるファイル名と行番号が、結果 
的に panic ! 呼び出しに導いた自分のコードの行ではなく、 panic ! マクロが呼び出されている他人の 
コードになるでしょう。 panic ! 呼び出しの発生元である関数のバックトレースを使用して、問題を起 
こしている自分のコードの箇所を割り出すことができます。バックトレースがどんなものか、次に議 
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論しましょう。 

9.1.2 parri c !バックトレースを使用する 

別の例を眺めて、自分のコードでマクロを直接呼び出す代わりに、コードに存在するバグにより、 
ライブラリで panic ! 呼び出しが発生するとどんな感じなのか確かめてみましょう。リスト 9-1 は、 
添え字でベクタの要素にアクセスを試みる何らかのコードです。 

フアイル名： src/main.rs 

fn mann () { 

let v = vec ! [1, 2, 3]; 

v [99]; 

} 

リスト 9-1： ベクタの境界を超えて要素へのアクセスを試み、 panic ! の呼び出しを発生させる 

ここでは、ベクタの 100 番目の要素（添え字は 0 始まりなので添え字 99) にアクセスを試みていま 
すが、ベクタには 3 つしか要素がありません。この場面では、 Rust はパニックします。 [] の使用は、 
要素を返すと想定されるものの、無効な添え字を渡せば、ここで Rust が返せて正しいと思われる要 
素は何もないわけです。 

他の言語 （C など）では、この場面で欲しいものではないにもかかわらず、まさしく要求したもの 
を返そうとしてきます：メモリがベクタに属していないにもかかわらず、ベクタ内のその要素に対応 
するメモリ上の箇所にあるものを何か返してくるのです。これは、 バッファー外読み出し （buffer 
overread; 訳注：バッファー読みすぎとも解釈できる か） と呼ばれ、攻撃者が、配列の後に格納された 
読めるべきでないデータを読み出せるように添え字を操作できたら、セキュリティ脆弱性につながる 
可能性があります。 

この種の脆弱性からプログラムを保護するために、存在しない添え字の要素を読もうとしたら、 
Rust は実行を中止し、継続を拒みます。試して確認してみましょう： 

$ cargo run 

Compiling panic v 0.1.0 (tn ie :/// projects / pamc ; 

Finished dev [unoptimized + debuginfo ] target ( s ) in 0.27 secs 
Running ' target / debug / panic ' 

thread ' main ' panicked at 'index out of bounds : the len is 3 but the index is 
99', / checkout / src / liballoc / vec . rs : 1555 : 10 
( , ma _ in , スレッドは 、/ checkout / src / li ’ balloc / vec . rs : 1555 : 10 の 
「境界外番号：長さは 3 なのに、添え字は 99 です」でパニックしました） 
note : Run with 'RUST BACKTRACE = l ' for a backtrace . 


このエラーは、自分のファイルではない vec . rs ファイルを指しています。標準ライブラリの 
vec < T > の実装です。ベクタ V に対して [] を使った時に走るコードは、 vec . rs に存在し、ここで実際 
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に panic! が発生しているのです。 

その次の注釈行は、 RUST_BACKTRACE 環境変数をセットして、まさしく何が起き、エラーが発生した 
のかのバックトレースを得られることを教えてくれています。バックトレースとは、ここに至るまで 
に呼び出された全関数の一覧です。 Rust のバックトレースも、他の言語同様に動作します：バックト 
レースを読むコツは、頭からスタートして自分のファイルを見つけるまで読むことです。そこが、問 
題の根源になるのです。自分のファイルを言及している箇所以前は、自分のコードで呼び出したコー 
ドになります；以後は、自分のコードを呼び出しているコードになります。これらの行には、 Rust の 
核となるコード、標準ライブラリのコード、使用しているクレートなどが含まれるかもしれません。 
RUST_BACKTRACE 環境変数を 0 以外の値にセットして、バックトレースを出力してみましょう。リス 
卜 9-2 のような出力が得られるでしょう。 

$ RUST_BACKTRACE=1 cargo run 

Finished dev [unoptimized + debuginfo 」 target(s)in 0.0 secs 
Running 'target/debug/panic' 

thread 'main 1 panicked at 'index out of bounds : the len is 3 but the index is 
99', /checkout/sre/liballoc/vec.rs : 1555 : 10 
stack backtrace : 

0: std :: sys :: imp: : backtrace :: tracing: : imp: : unwind_backtrace 

at /checkout/src/libstd/sys/urn x/backtrace/tracing/gcc_s.rs:49 
1:std :: sys_common :: backtrace: : _print 

at /checkout/sre/libstd/sys_common/backtrace.rs:71 
2 : std :: panieking: : default_h 00 k: : {{closure}} 

at /checkout/src/libstd/sys_common/backtrace.rs:60 
at /checkout/src/libstd/panicking.rs:381 
3 : std :: panicking: : default_hook 

at /checkout/src/libstd/panicking.rs:397 
4 : std :: panicking: : rust_panic_with_hook 

at /checkout/src/libstd/panicking.rs:611 
5 : std :: panicking: : begin_panic 

at /checkout/src/libstd/panicking.rs : 572 
6 : std :: panicking: : begin_panic_fmt 

at /checkout/src/libstd/panicking.rs:522 
7 : rust_begin_unwind 

at /checkout/src/libstd/panicking.rs:498 
8 : core::parricking: :panic_fmt 

at /checkout/src/libcore/panicKing.rs : 71 
9 : core: : panicking: : panic_bounds_check 

at /checkout/src/libcore/panicking.rs : 58 
10: <alloc: : vec: : Vec<T> as core::ops: : index::Index<usize>> :: index 
at /checkout/src/liballoc/vec.rs: 1555 
11 : panic :: main 

at sre/main.rs:4 
12: __rust_maybe_catch_panic 

at /checkout/sre/libpanic_unwind/lib.rs:99 
13: std :: rt : :lang_start 

at /checkout/src/libstd/panicking.rs:459 
at /checkout/src/libstd/panic.rs:361 
at /checkout/src/libstd/rt.rs : 61 


14: 


main 
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15: __ libc _ start_main 
16: < unknown > 

リスト 9-2： RUST _ BACKTRACE 環境変数をセッ ト した時に表示される、 panic ! 呼び出しが生成する 
バック トレース 

出力が多いです ね！ 0 S や Rust のバージョンによって、出力の詳細は変わる可能性があります。 
この情報とともに、バックトレースを得るには、デバッグシンボルを有効にしなければなりません。 
デノ《ッグシンボルは、 -- release オプションなしで cargo build や cargo run を使用していれば、標 
準で有効になり、ここではそうなっています。 

リスト 9-2 の出力で、バック トレースの 11 行目が問題発生箇所を指し示しています： src/main.rs 
の 4 行目です。プログラムにパニックしてほしくなければ、自分のファイルについて言及している 
最初の行で示されている箇所が、どのようにパニックを引き起こす値でこの箇所にたどり着いたか割 
り出すために調査を開始すべき箇所になります。バック トレースの 使用法を模擬するためにわざとパ 
ニックするコードを書いた リスト 9-1 において、パニックを解消する方法は、 3 つしか要素のないベ 
クタの添え字 99 の要素を要求しないことです。将来コードがパニックしたら、パニックを引き起こ 
すどんな値でコードがどんな動作をしているのかと、代わりにコードは何をすべきなのかを算出する 
必要があるでしょう。 

この章の後ほど、 「 panic ! するか panic ! するまいか」節で panic ! とエラー状態を扱うのに panic ! 
を使うべき時と使わぬべき時に戻ってきます。次は、 Result を使用してエラーから回復する方法を見 
ましょ' 5。 

9.2 Result で回復可能なエラー 

多くのエラーは、プログラムを完全にストップさせるほど深刻ではありません。時々、関数が失敗 
した時に、容易に解釈し、対応できる理由によることがあります。例えば、ファイルを開こうとして、 
ファイルが存在しないために処理が失敗したら、プロセスを停止するのではなく、ファイルを作成し 
たいことがあります。 

第 2 章の 「 Result 型で失敗する可能性に対処する」で Result enum が以下のように、 Ok と Err 
の2列挙子からなるよう定義されていることを思い出してください： 

enum Result < T , E > { 

Ok(T), 

Err ( E ), 

} 

T と E は、ジェネリックな型引数です：ジェネリクスについて詳しくは、第10章で議論します。 
たった今知っておく必要があることは、 T が成功した時に Ok 列挙子に含まれて返される値の型を表す 
ことと、 E が失敗した時に Err 列挙子に含まれて返される エラーの 型を表すことです。 Result はこの 
ようなジヱネリックな型引数を含むので、標準ライブラリ上に定義されている Result 型や関数など 
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を、成功した時とエラーの時に返したい値が異なるような様々な場面で使用できるのです。 

関数が失敗する可能性があるために Result 値を返す関数を呼び出しましょう：リスト 9-3 では、 
ファイルを開こうとしています。 

フアイル名： src / main.rs 
use std :: fs :: File ; 
fn mann () { 

let f = File : : open (" hello . txt ") ; 

} 

リスト 9-3: ファイルを開く 

File :: open が Result を返すとどう知るのでしょうか？標準ライブラリの API ドキュメントを参 
照することもできますし、コンパイラに尋ねることもできます！ f に関数の戻り値ではないと判明 
している型注釈を与えて、コードのコンパイルを試みれば、コンパイラは型が合わないと教えてくれ 
るでしょう。そして、エラーメッセージは、 f の実際の型を教えてくれるでしょう。試してみましょ 
う！ FUe::open の戻り値の型は u 32 ではないと判明しているので、 let f 文を以下のように変更し 
ましょう: 


let f: u32 = File: :open("hello. txt") ; 

これで コンパイル しようとすると、以下のような出力が得られます： 

error[E0308] : mismatched types 
(エラー： 型が合いません） 

-- > src/mann.rs:4:18 

I 

4 | let f: u32 = File::open("hello.txt"); 

| aaaaaaaaaaaaaaaaaaaaaaa expected u32, found enum 

'std :: result :: Result' 

I 

=note : expected type 'u32' 

( 注釈：予期した型は 'u32' です） 

found type 'std :: result :: Result<std :: fs :: File, std :: io :: Error>' 

( 実際の型は 、 std :: result: : Result く std: : fs : : File, std : : io: : Error 〉、 です） 

これにより、 File: :open 関数の戻り値の型は、 Result<T, E> であることがわかります 0 ジェネリッ 
ク引数の T は、ここでは成功値の型 std: :fs: :File で埋められていて、これはファイルハンドルで 
す。エラー値で使用されている E の型は、 std : : io : : Error です。 

この戻り値型は、 File: :open の呼び出しが成功し、読み込みと書き込みを行えるファイルハンドル 
を返す可能性があることを意味します。また、関数呼び出しは失敗もする可能性があります：例えば、 
ファイルが存在しない可能性、ファイルへのアクセス権限がない可能性です。 File::open には成功 
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したか失敗したかを知らせる方法とファイルハンドルまたは、エラー情報を与える方法が必要なので 
す。この情報こそが Result enum が伝達するものなのです。 

File : : open が成功した場合、変数 f の値はファイルハンドルを含む Ok インスタンスになります。 
失敗した場合には、発生したエラーの種類に関する情報をより多く含む Err インスタンスが f の値に 
なります。 

リスト 9-3 のコードに追記をして File :: open が返す値に応じて異なる動作をする必要がありま 
す。リスト 9-4 に基礎的な道具を使って Result を扱う方法を一つ示しています。第6章で議論した 
match 式です。 

ファイル名： src / main.rs 
use std :: fs :: File ; 
fn mann() { 

let f = File : : open (" hello . txt ") ; 

let f = match f { 

Ok ( file ) => file , 

Err (error) => { 

// ファイルを開く際に問題がありました 

panic ! ("There was a problem opening the file: {:?}", error) 

}, 

}； 

} 

リスト 9-4： match 式を使用して返却される可能性のある Result 列挙子を処理する 

option enum のように 、 Result enum とその列挙子は、初期化処理でインポートされているので、 
match アーム 内で Ok と Err ■列挙子の前に Result :: を指定する必要がないことに注目してください。 

ここでは、結果が Ok の時に、 Ok 列挙子から中身の fUe 値を返すように指示し、それからそのファ 
イルハンドル値を変数 f に代入しています。 match の後には、ファイルハンドルを使用して読み込ん 
だり書き込むことができるわけです。 

match のもう一つのアームは、 File : : open から Err 値が得られたケースを処理しています。この例 
では、 panic ! マクロを呼び出すことを選択しています。カレントディレクトリに hell 0. txt という 
ファイルがなく、このコードを走らせたら、 panic ! マクロからの以下のような出力を目の当たりにす 
るでしょう： 

thread 'mann' panicked at 'There was a problem opening the file: Error { repr: 

Os { code : 2 ， message : "No such file or directory" } }', src/main.rs:9:12 
('main' スレッドは、 src/mai n. rs: 9:12 の「ファイルを開く際に問題がありました ： Error 
{ repr: 

Os { code: 2, message : n そのような名前のファイルまたはディレクトリはありません 
” } } 」でパニック しました） 
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通常通り、この出力は、一体何がおかしくなったのかを物語っています。 

9.2.1 色々なエラーにマッチする 

リスト 9-4 のコードは、 File : :open が失敗した理由にかかわらず panic ! します。代わりにしたい 
ことは、失敗理由によって動作を変えることです：ファイルが存在しないために File : :open が失敗し 
たら、ファイルを作成し、その新しいファイルへのハンドルを返したいです。他の理由（例えばファイ 
ルを開く権限がなかったなど）で、 File : :open が失敗したら、リスト 9-4 のようにコードには panic ! 
してほしいのです。リスト 9-5 を眺めてください。ここでは match に別のアームを追加しています。 

フアイル名： src / main.rs 

use std :: fs :: File ; 
use std :: io :: ErrorKind ; 

fn main () { 

let f = File : : open (" hello . txt ") ; 

let f = match f { 

Ok ( file ) => file , 

Err (ref error ) if error . kind () == ErrorKind: : NotFound => { 
match File : : create (" hello . txt ") { 

Ok ( fc ) => fc , 

Err ( e ) => { 
panic ! ( 

// ファイルを作成しようとしましたが、問題がありました 

"Tried to create ri ie but tnere was a problem : {:?}", 


} 

}， 

Err ( error ) => { 
panic ! ( 

"There was a problem opening the file : {:?}", 
error 


}； 

} 

リスト 9-5: 色々な種類のエラーを異なる方法で扱う 

File : :open が Err 列挙子に含めて返す値の型は、 io : : Error であり、これは標準ライブラリで 
提供されている構造体です。この構造体には、呼び出すと io : : ErrorKind 値が得られる kind メ 
ソッドがあります。 io : : Error*Kind という enum は、標準ライブラリで提供されていて、 io 処理 
の結果発生する可能性のある色々な種類のエラーを表す列挙子があります。使用したい列挙子は、 
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ErrorKi nd : : Not Found で、これは開こうとしているフアイルがまだ存在しないことを不唆します。 

if error . kind () == ErrorKi nd : : Notfound という条件式は、マッチガードと呼ばれます：アーム 
のパターンをさらに洗練する match アーム上のおまけの条件式です。この条件式は、そのアームの 
コードが実行されるには真でなければいけないのです；そうでなければ、パターンマッチングは継続 
し、 match の次のアームを考慮します。パターンの ref は、 error がガード条件式にムーブされないよ 
うに必要ですが、ただ単にガード式に参照されます。 ref を使用して&の代わりにパターン内で参照 
を作っている理由は、第18章で詳しく講義します。手短に言えば、パターンの文脈において、&は参 
照にマッチし、その値を返しますが、 ref は値にマッチし、それへの参照を返すということなのです。 

マッチガードで精査したい条件は、 error . kind () により返る値が、 ErrorKi nd enum の NotFound 
列挙子であるかということです。もしそうなら、 File : :create でファイル作成を試みます。ところ 
が、 File : : create も失敗する可能性があるので、内部にも match 式を追加する必要があるのです。 
ファイルが開けないなら、異なるエラーメッセージが出力されるでしょう。外側の match の最後の 
アームは同じままなので、フアイルが存在しないエラー以外ならプログラムはパニックします。 


9.2.2 エラー時にパニックするシヨートカット： unwrap と expect 

match の使用は、十分に仕事をしてくれますが、いささか冗長になり得る上、必ずしも意図をよく 
伝えるとは限りません。 Results , E > 型には、色々な作業をするヘルパーメソッドが多く定義されて 
います。それらの関数の一つは、 unwrap と呼ばれますが、リスト 9-4 で書いた match 式と同じように 
実装された短絡メソッドです。 Result 値が Ok 列挙子なら、 unwrap は Ok の中身を返します。 Result 
が Err 列挙子なら、 unwrap は panic ! マクロを呼んでくれます。こちらが実際に動作している unwrap 
の例です： 

ファイル名： src / main.rs 
use std :: fs :: File ; 
fn mann () { 

let f = File : : open (" hello . txt ") . unwrapO ; 

} 

このコードを liello.txt ファイルなしで走らせたら、 unwrap メソッドが行う panic ! 呼び出しから 
の エラー メッ セージを 目の当たりにするでしょう： 

thread ' mann ' panicked at 'called Result: : unwrapO on an Err value : Error { 
repr : Os { code : 2, message : "No such file or directory 11 } }', 
src / libcore / result . rs :906:4 

(’ main 1 スレッドは、 src / libcore/result • rs : 906:4 の 
r Err ' 値に対して ' Result : : unwrapO 、が呼び出されました： Error { 

repr : Os { code : 2, message : n そのようなファイルまたはディレクトリはありません 11 
} } 」でパニックしました） 
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別のメソッド expect は、 unwrap に似ていますが、 panic ! のエラーメッセージも選択させてくれ 
ます。 unwrap の代わりに expect を使用して、いいエラーメッセージを提供すると、意図を伝え、パ 
ニックの原因をたどりやすくしてくれます。 expect の表記はこんな感じです： 

フアイル名： src / main.rs 
use std :: fs :: File ; 
fn mann () { 

// hello , txt を開くのに失敗しました 

let f = File : : open (" hello . txt ") . expect ("Failed to open hello . txt ") ; 

} 

expect を unwrap と同じように使用してます：ファイルハンドルを返したり、 panic ! マクロを 呼び 
出しています。 expect が panic ! 呼び出しで使用するエラーメッセージは、 unwrap が使用するデフォ 
ルトの panic ! メッセージではなく、 expect に渡した引数になります。以下のようになります： 

thread ' mann ' panicked at 'Failed to open hello . txt : Error { repr : Os i code : 

2, message : "No such file or directory " } }', src / libcore / result . rs : 906:4 

この エラー メ ッ セージは、指定したテキストの heUo.txt を開くのに失敗しましたで 始まっているので、 
コード内のどこで エラー メッセージが出力されたのかより見つけやすくなるでしょう。複数箇所で 
unwrap を使用していたら、ズバリどの unwrap がパニックを引き起こしているのか理解するのは、よ 
り時間がかかる可能性があります。パニックする unwrap 呼び出しは全て、同じメッセージを出力す 
るからです。 

9.2.3 エラーを委譲する 

失敗する可能性のある何かを呼び出す実装をした関数を書く際、関数内でエラーを処理する代わり 
に、呼び出し元がどうするかを決められるようにエラーを返すことができます。これはエラーの委譲 
として認知され、自分のコードの文脈で利用可能なものよりも、エラーの処理法を規定する情報や口 
ジックがより多くある呼び出し元のコードに制御を明け渡します。 

例えば、リスト 9-6 の関数は、ファイルからユーザ名を読み取ります。ファイルが存在しなかった 
り、読み込みできなければ、この関数はそのようなエラーを呼び出し元のコードに返します。 

フ アイ ル名： src / main.rs 

use std :: io ; 
use std :: io : : Read ; 
use std :: fs :: File ; 

fn read _ username_f rom_fi le () -> Resu Lt<Stri ng , io :: Err * or *> { 
let f = File : : open (" hello . txt ") ; 
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let mut t = match f { 

Ok(file) => file ， 

Err (e) => return Err (e), 

}； 

let mut s = Stri ng: : new(); 

match f.read_to_stri ng(&mut s) { 
Ok し ） => Ok(s) , 

Err(e) => Err (e), 



リスト 9-6： match でエラーを呼び出し元のコードに返す関数 

まずは、関数の戻り値型に注目してください： Result<String, io : : Error> です。つまり、この関 
数は、 Result<T, E> 型の値を返しているということです。ここでジェネリック引数の T は、具体型 
String で涅められ、ジヱネリック引数の E は具体型 io : : Error で埋められています。この関数が何 
の問題もなく成功すれば、この関数を呼び出したコードは、 String (関数がファイルから読み取った 
ユーザ名）を保持する Ok 値を受け取ります。この関数が何か問題に行き当たったら、呼び出し元の 
コードは io::Error のイ ンスタンス を保持する Err 値を受け取り、この io :: Error は問題の内容に 
関する情報をより多く含んでいます。関数の戻り値の型に io :: Err 0r を選んだのは、この関数本体 
で呼び出している失敗する可能性のある処理が両方とも偶然この型をエラー値として返すからです: 
File: : open 関数と read_to_string メソッドです。 

関数の本体は、 File: :open 関数を呼び出すところから始まります。そして、リスト 9-4 の match に 
似た match で返ってくる Result 値を扱い、 Err ケースに panic! を呼び出すだけの代わりに、この関 
数から早期リターンしてこの関数のエラー値として、 File:: open から得たエラー値を呼び出し元に渡 
し戻します。 FUe :: open が成功すれば、ファイルハンドルを変数 f に保管して継続します。 

さらに、変数 s に新規 String を生成し、 f の ファイルハンドル に対して read_to_string を呼び出 
して、 ファイルの 中身を s に読み出します。 File: :open が成功しても、失敗する可能性があるので、 
read_to_string メソッドも、 Result を返却します。その Result を処理するために別の match が必要 
になります： read_to_string が成功したら、関数は成功し、今は Ok に包まれた s に入っている ファ 
イルのユーザ 名を返却します。 read_to_stri ng が失敗したら、 File: :open の民り値を扱った match 
でエラー値を返したように、エラー値を返します。しかし、明示的に return を述べる必要はありま 
せん。これが関数の最後の式だからです。 

そうしたら、呼び出し元のコードは、ユーザ名を含む Ok 値か、 io :: Error を含む Err 値を得て扱い 
ます。呼び出し元のコードがそれらの値をどうするかはわかりません。呼び出しコードが Err 値を得 
たら、例えば、 panic! を呼び出してプログラムをクラッシュさせたり、デフォルトのユーザ名を使っ 
たり、ファイル以外の場所からユーザ名を検索したりできるでしょう。呼び出し元のコードが実際に 
何をしようとするかについて、十分な情報がないので、成功や失敗情報を全て委譲して適切に扱える 
ようにするのです。 
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Rust において、この種の エラー 委譲は非常に一般的なので、 Rust にはこれをしやすくする？演算 
子が用意されています。 

9.2.3. 1エラー委譲のシヨートカツト：？演算子 

リスト 9-7 もリスト 9-6 と同じ機能を有する read _ username_f rom _ file の実装ですが、こちらは？ 
演算子を使用しています： 

フアイル名： src / main.rs 

use std :: io ; 
use std : : io : : Read ; 
use std :: fs :: Fi le ; 

fn read _ username _ from _ file () -> Result < Stri ng , io :: Error > { 
let mut f = File : : open (" hello . txt ") ?; 
let mut s = Stri ng : : new (); 
f . read _ to _ string(&mut s )?; 

Ok ( s ) 

} 

リスト 9-7: ? 演算子でエラーを呼び出し元に返す関数 

Result 値の直後に置かれた？は、リスト 9-6 で Result 値を処理するために定義した match 式とほ 
ぼ同じように動作します。 Result の値が Ok なら、 Ok の中身がこの式から返ってきて、プログラムは 
継続します。値が Err なら、 return キーワードを使ったかのように関数全体から Err の中身が返っ 
てくるので、 エラー 値は呼び出し元のコードに委譲されます。 

リスト 9-6 の match 式と？演算子には違いがあります：？を使ったエラー値は、標準ライブラリの 
From トレイトで定義され、エラーの型を別のものに変換する from 関数を通ることです。？演算子が 
from 関数を呼び出すと、受け取ったエラー型が現在の関数の戻り値型で定義されているエラー型に変 
換されます。これは、個々がいろんな理由で失敗する可能性があるのにも関わらず、関数が失敗する 
可能性を全て一つのエラー型で表現して返す時に有用です。各エラー型が from 関数を実装して返り 
値のエラー型への変換を定義して いる 限り、？演算子が変換の面倒を自動的に見てくれます。 

リスト 9-7 の文脈では、 FUe :: open 呼び出し末尾の？は Ok の中身を変数 f に返します。 エラーが 
発生したら、？演算子により関数全体から早期リターンし、あらゆる Err 値を呼び出し元に与えます。 
同じ法則が read _ to_stri ng 呼び出し末尾の？にも適用されます。 

?演算子により定型コードの多くが排除され、この関数の実装を単純にしてくれます。リスト 9-8 
で示したように、？の直後のメソツド呼び出しを連結することでさらにこのコードを短くすることさ 
えもできます。 

フアイル名： src / main.rs 


use std :: io ; 
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use std : : io : : Read ; 
use std :: ts : : File ; 

fn read _ username _ from _ file () -> Result < Stri ng , io :: Error > { 
let mut s = Stri ng : : new (); 

File : : open (" hello . txt ") ?. read _ to _ stri ng(&mut s )?; 


Ok ( s ) 

} 

リスト 9-8: ? 演算子の後のメソッド呼び出しを連結する 

s の新規 String の生成を関数の冒頭に移動しました；その部分は変化していません。変数 f を生成 
する代わりに、 read _ to_stri ng の呼び出しを直接 File : : open ("hello • txt ") ?の結果に連結させま 
した。それでも、 read _ to _ string 呼び出しの末尾には？があり、 Fi 1 e :: open と 「 ead _ to_stri ng 両方 
が成功したら、エラーを返すというよりもそれでも、 s にユーザ名を含む Ok 値を返します。機能もま 
たリスト 9-6 及び、 9-7 と同じです；ただ単に異なるバージョンのよりエルゴノミックな書き方なの 
です。 


9 . 23.2 ?演算子は、 Result を返す関数でしか使用できない 

?演算子は戻り値に Result を持つ関数でしか使用できません。というのも、リスト 9-6 で定義した 
match 式と同様に動作するよう、定義されているからです。 Result の戻り値型を要求する match の部 
品は 、 return Err ( e ) なので、関数の戻り値はこの return と互換性を保つために Result でなければ 
ならないのです。 

ma i n 関数で？演算子を使用したらどうなるか見てみましょう 。 ma i n 関数は、戻り値が （） でしたね: 
use std :: fs :: File ; 
fn main () { 

let f = File : : open (" hello . txt ") ?; 

} 


この コー ドを コンパイル すると、以下のような エラー メ ッ セージが得られます: 


error[E0277] : the trait bound () : std :: ops :: Try is not satisfied 
(エラー： 、 （） ： std : : ops :: Try' というトレイト境界が満たされていません） 
——> src/mann.rs :4:13 


4 


let f = File :: open (" hello . txt ")?; 


the '7 operator can only be used in a function that returns 
Result ' (or another type that implements ' std :: ops :: Try ') 
in this macro invocation 

( このマクロ呼び出しの ' Result '( かまたは、 std : : ops :: Try ' を実装する 
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他の型）を返す関数でしか '?' 演算子は使用できません） 

I 

= he ip : the trait ' std :: ops :: Try is not implemented tor () 

( 助言：、 std : : ops :: Try ' トレイトは '() 、 には実装されていません） 

= note : required by ' std :: ops : : Try : : from _ error ' 

( 注釈： ' std : : ops : : Try : : f rom _ error ' で要求されています） 

このエラーは、？演算子は Result を返す関数でしか使用が許可されないと指摘しています。 Result 
を返さない関数では、 Result を返す別の関数を呼び出した時、？演算子を使用してエラーを呼び出し 
元に委譲する可能性を生み出す代わりに、 match か Result のメソッドのどれかを使う必要があるで 
しょう。 

さて、 panic ! 呼び出しや Result を返す詳細について議論し終えたので、どんな場合にどちらを使 
うのが適切か決める方法についての話に戻りましょう。 

9.3 parHc !すべきかするまいか 

では、 panic ! すべき時と Result を返すべき時はどう決定すればいいのでしょうか？コードがパ 
ニックしたら、回復する手段はありません。回復する可能性のある手段の有る無しに関わらず、どん 
なエラー場面でも panic ! を呼ぶことはできますが、そうすると、呼び出す側のコードの立場に立っ 
てこの場面は回復不能だという決定を下すことになります。 Result 値を返す決定をすると、決断を下 
すのではなく、呼び出し側に選択肢を与えることになります。呼び出し側は、場面に合わせて回復を 
試みることを決定したり、この場合の Err 値は回復不能と断定して、 panic ! を呼び出し、回復可能 
だったエラーを回復不能に変換することもできます。故に、 Result を返却することは、失敗する可能 
性のある関数を定義する際には、いい第一選択肢になります。 

稀な場面では、 Result を返すよりもパニックするコードを書く方がより適切になることもありま 
す。例やプロトタイプコード、テストでパニックするのが適切な理由を探究しましょう。それから 
コンパイラは失敗することはないとわからないけれど、人間はできる場面を議論しましょう。そし 
て、ライブラリコードでパニックするか決定する方法についての一般的なガイドラインで結論づけま 
しょう。 

9.3.1 例、プロトタイプコード、テスト 

例を記述して何らかの概念を具体化している時、頑健なエラー処理コードも例に含むことは、例の 
明瞭さを欠くことになりかねません 0 例において、 unwrap などのパニックする可能性のあるメソッド 
呼び出しは、アプリケーシヨンにエラーを処理してほしい方法へのプレースホルダーを意味している 
と理解され、これは残りのコードがしていることによって異なる可能性があります。 

同様に、 unwrap や expect メソッドは、エラーの処理法を決定する準備ができる前、プロトタイプ 
の段階では、非常に便利です。それらにより、コードにプログラムをより頑健にする時の明らかな 
マーカーが残されるわけです。 
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メソッド呼び出しがテスト内で失敗したら、そのメソッドがテスト下に置かれた機能ではなかった 
としても、テスト全体が失敗してほしいでしょう。 panic ! が、テストが失敗と印づけられる手段なの 
で、 unwrap や expect の呼び出しは スバ リ起こるべきことです。 

9.3.2 コンパイラよりもプログラマがより情報を持っている場合 

Result が Ok 値であると確認する何らかの別のロジックがある場合、 unwrap を呼び出すことは適切 
でしょうが、コンパイラは、そのロジックを理解はしません。それでも、処理する必要のある Result 
は存在するでしょう：呼び出している処理が何であれ、自分の特定の場面では論理的に起こり得なく 
ても、一般的にまだ失敗する可能性はあるわけです。手動でコードを調査して Err 列挙子は存在しな 
いと確認できたら、 unwrap を呼び出すことは完全に受容できることです。こちらが例です： 

use std : : net : : IpAddr * ; 

Let home : IpAddr = "127• 0 . 0 .1" • parse ()• unwrapu ; 

ハードコードされた文字列を構文解析することで IpAddr インスタンスを生成しています。プログ 
ラマには 127.0.0.1 が合法な IP アドレスであることがわかるので、ここで unwrap を使用すること 
は、受容可能なことです。しかしながら、ハードコードされた合法な文字列が存在することは、 parse 
メソッドの戻り値型を変えることにはなりません：それでも得られるのは、 Result 値であり、コンパ 
イラはまだ Err 列挙子になる可能性があるかのように Result を処理することを強制してきます。コ 
ンパイラは、この文字列が常に合法な IP アドレスであると把握できるほど利口ではないからです。プ 
ログラムにハードコードされるのではなく、 IP アドレス文字列がユーザ起源でそれ故に確かに失敗す 
る可能性がある場合、絶対に Result をもっと頑健な方法で代わりに処理したくなるでしょう。 

9.3.3 エラー処理のガイドライン 

コードが悪い状態に陥る可能性があるときにパニックさせるのは、推奨されることです。この文脈 
において、悪い状態とは、何らかの前提、保証、契約、不変性が破られたことを言い、例を挙げれば、 
無効な値、矛盾する値、行方不明な値がコードに渡されることと、さらに以下のいずれか一つ以上の 
状態であります： 

• 悪い状態がときに起こるとは予想されないとき。 

• この時点以降、この悪い状態にないことを頼りにコードが書かれているとき。 

• 使用している型にこの情報をコード化するいい手段がないとき。 

誰かが自分のコードを呼び出して筋の通らない値を渡してきたら、最善の選択肢は panic ! し、開 
発段階で修正できるように自分たちのコードにバグがあることをライブラリ使用者に通知することか 
もしれません。同様に自分の制御下にない外部コードを呼び出し、修正しようのない無効な状態を返 
すときに panic ! はしばしば適切です。 
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しかし、どんなにコードをうまく書いても起こると予想されますが、悪い状態に達したとき、それ 
でも panic ! 呼び出しをするよりも、 Result を返すほうがより適切です。例には、不正なデータを渡 
されたパーサとか、訪問制限に引っかかったことを示唆するステータスを返す HTTP V クエストなど 
が挙げられます。このような場合には、呼び出し側が問題の処理方法を決定できるように Result を 
返してこの悪い状態を委譲して、失敗が予想される可能性であることを示唆するべきです。 panic ! を 
呼び出すことは、これらのケースでは最善策ではないでしょう。 

コードが値に対して処理を行う場合、コードはまず値が合法であることを確認し、値が合法でなけ 
ればパニックするべきです。これはほぼ安全性上の理由によるものです：不正なデータの処理を試み 
ると、コードを脆弱性に晒す可能性があります。これが、境界外へのメモリアクセスを試みたときに 
標準ライブラリが panic ! を呼び出す主な理由です：現在のデータ構造に属しないメモリにアクセスを 
試みることは、ありふれたセキュリティ問題なのです。関数にはしばしば契約が伴います：入力が特 
定の条件を満たすときのみ、振る舞いが保証されるのです。契約が侵されたときにパニックすること 
は、道理が通っています。なぜなら、契約侵害は常に呼び出し側のバグを示唆し、呼び出し側に明示的 
に処理してもらう必要のある種類のエラーではないからです。実際に、呼び出し側が回復する合理的 
な手段はありません；呼び出し側のプログラマがコードを修正する必要があるのです。関数の契約は、 
特に侵害がパニックを引き起こす際には、関数の API ドキュメント内で説明されているべきです。 

ですが、全ての関数でたくさんのエラーチェックを行うことは冗長で煩わしいことでしょう。幸運 
にも、 Rust の型システム（故にコンパイラが行う型精査）を使用して多くの検査を行ってもらうこと 
ができます。関数の引数に特定の型があるなら、合法な値があるとコンパイラがすでに確認している 
ことを把握して、コードのロジックに進むことができます。例えば、 Option 以外の型がある場合、プ 
ログラムは、何もないではなく何かあると想定します。そうしたらコードは、 Some と None 列挙子の 
2つの場合を処理する必要がなくなるわけです：確実に値があるという可能性しかありません。関数 
に何もないことを渡そうとしてくるコードは、コンパイルが通りもしませんので、その場合を実行時 
に検査する必要はないわけです。別の例は、 U 32 のような符号なし整数を使うことであり、この場合、 
引数は負には絶対にならないことが確認されます。 

9.3.4 検証のために独自の型を作る 

Rust の型システムを使用して合法な値があると確認するというアイディアを一歩先に進め、検証 
のために独自の型を作ることに目を向けましょう。第2章の数当てゲームで、コードがユーザに1か 
ら100までの数字を推測するよう求めたことを思い出してください。秘密の数字と照合する前にユー 
ザの推測がそれらの値の範囲にあることを全く確認しませんでした；推測が正であることしか確認し 
ませんでした。この場合、結果はそれほど悲惨なものではありませんでした：「大きすぎ」、「小さすぎ」 
という出力は、それでも正しかったでしょう。ユーザを合法な推測に導き、ユーザが範囲外の数字を 
推測したり、例えばユーザが文字を代わりに入力したりしたときに別の挙動をするようにしたら、有 
益な改善になるでしょう。 

これをする一つの方法は、ただの u 32 の代わりに i 32 として推測をパースし、負の数になる可能性 
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を許可し、それから数字が範囲に収まっているというチヱックを追加することでしょう。そう、以下 
のように： 


loop { 

// -- smp -- 

let guess : 1 32 = match guess . tnm () .parseu { 
Ok ( num ) => num , 

Err (_) => continue , 

}； 


if guess < 1 || guess > 100 { 

println! ("The secret number will be between 1 and 100 . ; 
continue ; 

} 

match guess . cmp (& secret _ number ) { 

// -- snip -- 


この if 式が、値が範囲外かどうかをチヱックし、ユーザに問題を告知し、 continue を呼び出して 
ループの次の繰り返しを始め、別の推測を求めます。 if 式の後、 guess は1から100の範囲にある 
と把握して、 guess と秘密の数字の比較に進むことができます。 

ところが、これは理想的な解決策ではありません：プログラムが1から100の範囲の値しか処理し 
ないことが間違いなく、肝要であり、この要求がある関数の数が多ければ、このようなチェックを全 
関数で行うことは、面倒でパフォーマンスにも影響を及ぼす可能性があるでしょう。 

代わりに、新しい型を作って検証を関数内に閉じ込め、検証を全箇所で繰り返すのではなく、その 
型の インスタンスを 生成することができます。そうすれば、関数がその新しい型をシグ ニ チャに用い、 
受け取った値を自信を持って使用することは安全になります。リスト 9-9 に、 new 関数が1から100 
までの値を受け取った時のみ、 Guess の インスタンスを 生成する Guess 型を定義する一つの方法を示 
しました。 


pub struct uuess { 
value : u 32 , 

} 


impl Guess { 

pub fn new ( value : u 32) -> Guess { 
if value < 1 || value > 100 { 

// 予想の値は 1 から 100 の範囲でなければなりませんが、 {} でした 

□ amc ! ("Guess value must be between 1 and 100 , got value ); 

} 

Guess { 
va lue 


} 


} 
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pub fn value(&self) -> u32 { 
selr .value 

} 

} 

リスト 9-9： 値が 1 から100の場合のみ処理を継続する Guess 型 

まず、 u32 型の value をフィールドに持つ Guess という名前の構造体を定義しています。ここに数 
値が保管されます。 

それから Guess に Guess 値のインスタンスを生成する new という名前の関連関数を実装していま 
す。 new 関数は、 u32 型の value という引数を取り、 Guess を返すように定義されています。 new 関数 
の本体のコードは、 value をふるいにかけ、 1 から 100 の範囲であることを確かめます。 value がふ 
るいに引っかかったら、 panic! 呼び出しを行います。これにより、呼び出しコードを書いているプ 
ログラマに、修正すべきバグがあると警告します。というのも、この範囲外の value で Guess を生 
成することは、 Guess : : new が頼りにしている契約を侵害するからです。 Guess : : new がパニックする 
かもしれない条件は、公開されている API ドキュメントで議論されるべきでしょう；あなたが作成す 
る API ドキュメントで parric! の可能性を示唆する、ドキュメントの規約は、第14章で講義します。 
value が確かにふるいを通ったら、 value フイールドが value 引数にセットされた新しい Guess を作 
成して返します。 

次に、 self を借用し、他に引数はなく、 u32 を返す value というメソッドを実装します。この類 
のメソッドは時にゲッターと呼ばれます。目的がフィールドから何らかのデータを得て返すことだか 
らです。この公開メソッドは、 Guess 構造体の value フィールドが非公開なので、必要になります。 
value フィールドが非公開なことは重要であり、そのために Guess 構造体を使用するコードは、直接 
value をセットすることが叶わないのです：モジュール外のコードは、 Guess : : new 関数を使用して 
Guess のインスタンスを生成しなければならず、それにより、 Guess :: new 関数の条件式でチヱックさ 
れていない value が Guess に存在する手段はないことが保証されるわけです。 

そうしたら、引数を一つ持つか、1から100の範囲の数値のみを返す関数は、シグニチャで u32 で 
はなく、 Guess を取るか返し、本体内で追加の確認を行う必要はなくなると宣言できるでしょう。 

9.4 まとめ 

Rust の エラー 処理機能は、プログラマがより頑健なコードを書く手助けをするように設計されて 
います。 parric! マクロは、プログラムが処理できない状態にあり、無効だったり不正な値で処理を 
継続するのではなく、プロセスに処理を中止するよう指示することを通知します。 Result enum は、 
Rust の型システムを使用して、コードが回復可能な方法で処理が失敗するかもしれないことを示唆 
します。 Result を使用して、呼び出し側のコードに成功や失敗する可能性を処理する必要があること 
も教えます。適切な場面で panic! や Result を使用することで、必然的な問題の眼前でコードの信頼 
性を上げてくれます。 
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今や、標準ライブラリが option や Result enum などでジェネリクスを有効活用するところを目 
の当たりにしたので、ジェネリクスの動作法と自分のコードでの使用方法について語りましょう。 
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10； 


ジェネリック型、トレイト、ライフタ 
イム 


全てのプログラミング言語には、概念の重複を効率的に扱う道具があります。 Rust において、その 
ような道具の一つがジェネリクスです。ジヱネリクスは、具体型や他のプロパティの抽象的な代役で 
す。コード記述の際、コンパイルやコード実行時に、ジヱネリクスの位置に何が入るかを知ることな 
く、ジェネリクスの振る舞いや他のジェネリクスとの関係を表現できるのです。 

関数が未知の値の引数を取り、同じコードを複数の具体的な値に対して走らせるように、彳32や 
String などの具体的な型の代わりに何かジェネリックな型の引数を取ることができます。実際、第 
6 章で Option < T > 、第 8 章で Vec < T > と HashMap < K , V > 、第 9 章で Result < T , E > を既に使用しまし 
た。この章では、独自の型、関数、メソッドをジヱネリクスとともに定義する方法を探究します！ 

まず、関数を抽出して、コードの重複を減らす方法を確認しましょう。次に同じテクニックを活用 
して、引数の型のみが異なる2つの関数からジェネリックな関数を生成します。また、ジェネリック 
な型を構造体や enum 定義で使用する方法も説明します。 

それから、トレイトを使用して、ジュネリックな方法で振る舞いを定義する方法を学びます。ジェ 
ネリックな型のあるトレイトを組み合わせてただ単にどんな型に対してもとは対照的に、ジェネリッ 
クな型を特定の振る舞いのある型のみに制限することができます。 

最後に、ライフタイムを議論します。ライフタイムとは、コンパイラに参照がお互いにどう関係し 
ているかの情報を与える1種のジェネリクスです。ライフタイムのおかげでコンパイラに参照が合法 
であることを確認してもらうことを可能にしつつ、多くの場面で値を借用できます。 

10.1 関数を抽出することで重複を取り除く 

ジェネリクスの記法に飛び込む前にまずは、関数を抽出することでジェネリックな型が関わらない 
重複を取り除く方法を見ましょう。そして、このテクニックを適用してジェネリックな関数を抽出す 
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るのです！重複したコードを認識して関数に抽出できるのと同じように、ジェネリクスを使用できる 
重複コードも認識し始めるでしょう。 

リスト 10-1 に示したように、リスト内の最大値を求める短いプログラムを考えてください。 

フアイル名： src / main.rs 

fn mann() { 

let number_list = vec! [34, 50 ， 25 ， 100 ， 65]; 

let mut largest = number_list[0]; 

for number in number_list { 
if number > Largest { 
largest = number; 

} 

} 

// 最大値は {} です 

println! ("The largest number is {}" ,largest); 

# assert_eq! (largest, 100) ; 

} 

リスト 10-1: 数字のリストから最大値を求めるコード 

このコードは、整数のリストを変数 number _ list に格納し、リストの最初の数字を largest という 
変数に配置しています。それからリストの数字全部を走査し、現在の数字が largest に格納された数 
値よりも大きければ、その変数の値を置き換えます。ですが、現在の数値が今まで見た最大値よりも 
小さければ、変数は変わらず、コードはリストの次の数値に移っていきます。リストの数値全てを吟 
味した後、 largest は最大値を保持しているはずで、今回は100になります。 

2つの異なる数値のリストから最大値を発見するには、リスト 10-1 のコードを複製し、プログラ 
ムの 異なる2箇所で同じロジックを使用できます。リスト 10-2 のようにですね。 

フアイル名： src / main.rs 

fn mann() { 

let number_list = vec! [34, 50 ， 25 ， 100 ， 65]; 

let mut largest = number_list[0]; 

for number in number_list { 
if number > largest { 
largest = number; 

} 

} 


println! ("The largest number is {}" , largest ); 



第 10 章ジェネリック型、トレイト、ライフタイム 


184 


let number_list = vec ! [102 , 34, 6000， 89， 54, 2, 43， 8]; 

let mut largest = number _ list [0]; 

for number in number_list { 
if number > largest { 
largest = number ; 

} 

} 

println! ("The largest number is {}" , largest ); 

} 

リスト 10-2: 2 つの数値のリストから最大値を探すコード 

このコードは動くものの、コードを複製することは退屈ですし、間違いも起きやすいです。また、 
複数箇所のコードを変更したい時に更新しなければなりません。 

この重複を排除するには、弓I数で与えられた整数のどんなリストに対しても処理が行える関数を定 
義して抽象化できます。この解決策によりコードがより明確になり、リストの最大値を探すという概 
念を抽象的に表現させてくれます。 

リスト 10-3 では、最大値を探すコードを largest という関数に抽出しました。リスト 10-1 のコー 
ドは、たった1つの特定のリストからだけ最大値を探せますが、それとは異なり、このプログラムは 
2つの異なるリストから最大値を探せます。 

フ アイ ル名： src/main.rs 

fn largest ( list : & [ i 32]) -> i 32 { 
let mut largest = list [0]; 

for &itern in list . iter () { 
if item > largest { 
largest = item ; 

} 

} 

largest 

} 

fn main () { 

let number_list = vec ! [34， 50， 25，100， 65]; 

let result = largest (& number _ list ); 

println! ("The largest number is {}" , result ); 

# assert _ eq ! ( result , 100) ; 

let number_list = vec ! [102， 34， 6000， 89， 54, 2, 43， 8]; 

let result = largest (& number _ list ); 
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pnntln ! ("The largest number is {}" , result ); 

# assert _ eq ! ( result , 6000); 

} 

リスト 10-3: 2 つのリスト から最大値を探す抽象化された コード 

largest 関数には list と呼ばれる引数があり、これは、関数に渡す可能性のあるあらゆる i 32 値 
の具体的なスライスを示します。結果的に、関数呼び出しの際、コードは渡した特定の値に対して走 
るのです。 

まとめとして、こちらがリスト 10-2 のコードからリスト 10-3 に変更するのに要したステップです: 

1. 重複したコードを認識する。 

2. 重複コードを関数本体に抽出し、コードの入力と戻り値を関数シグニチヤで指定する。 

3. 重複したコードの2つの実体を代わりに関数を呼び出すように更新する。 

次は、この同じ手順をジェネリクスでも踏んで異なる方法でコードの重複を減らします。関数本体 
が特定の値ではなく抽象的な list に対して処理できたのと同様に、ジェネリクスは抽象的な型に対 
して処理するコードを可能にしてくれます。 

例えば、関数が2つあるとしましょう：1つは i 32 値のスライスから最大の要素を探し、1つは 
char 値のスライスから最大要素を探します。この重複はどう排除するのでしょうか？答えを見つけ 
ましょ5 ! 

10.2 ジェネリックなデータ型 

関数 シ グニチヤや構造体などの要素の定義を生成するのにジヱネリクスを使用することができ、そ 
れはさらに他の多くの具体的なデータ型と使用することもできます。まずは、ジェネリクスで関数、 
構造体、 enum 、 メソッドを定義する方法を見ましょう。それから、ジヱネリクスがコードのパフォー 
マンスに 与える影響を議論します。 

10.2.1 関数定義では 

ジェネリクスを使用する関数を定義する時、通常、引数や戻り値のデータ型を指定する関数のシグ 
ニチヤにジヱネリクスを配置します。そうすることでコードがより柔軟になり、コードの重複を阻止 
しつつ、関数の呼び出し元により多くの機能を提供します。 

largest 関数を続けます。リスト 10-4 はどちらもスライスから最大値を探す2つの関数を示して 
います。 

フ アイ ル名： src / main.rs 

fn largest _ i 32 ( list : & [ i 32]) -> i 32 { 
let mut largest = list [0]; 
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tor &itern in list . iter () { 
if item > largest { 
largest = item ; 

} 

} 

largest 

} 

fn largest _ char ( list : & [ char ] ) -> char { 
let mut largest = It st [0]; 

for &item in list . iter () { 
if item > largest { 
largest = item ; 

} 

} 

largest 

} 

fn main () { 

let number_list = vec ! [34, 50， 25，100， 65]; 

let result = largest _ i 32(& number _ list ); 

println! ("The largest number is {}" , result ); 

# assert _ eq ! ( result , 100) ; 

let char 一 list = vec ! [' y ', ' m ', ' a ', ' q ']; 

let result = largest _ char (& char _ list ); 
println! ("The largest char is {}" , result ); 

# assert _ eq ! ( result , ' y '); 

} 

リスト 10-4: 名前とシグニチャの型のみが異なる2つの関数 

1 argest _ i _32 関数は、リスト 10-3 で抽出したスライスから最大の132を探す関数です。 
1 argest _ char 関数は、スライスから最大の char を探します。関数本体には同じコードがあるので、 
単独の関数にジェネリックな型引数を導入してこの重複を排除しましょう。 

これから定義する新しい関数の型を引数にするには、ちょうど関数の値引数のように型引数に名前 
をつける必要があります。型引数の名前にはどんな識別子も使用できますが、 T を使用します。とい 
うのも、慣習では、 Rust の弓 I 数名は短く（しばしばたった1文字になります)、 Rust の型の命名規則 
がキャメルケースだからです。” type ” の省略形なので、 t が多くの Rust プログラマの規定の選択な 
のです。 

関数の本体で引数を使用すると、 コンパイラ がその名前の意味を把握できるようにシグ ニ チャでそ 
の引数名を宣言しなければなりません。同様に、型引数名を関数シグニチャで使用する際には、使用 
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する前に型引数名を宣言しなければなりません。ジェネリックな largest 関数を定義するために、型 
名宣言を山カッコ （<>) 内、関数名と引数リストの間に配置してください。こんな感じに： 

fn largest く T >( list : & [ T ]) -> T { 

この定義は以下のように解読します：関数 largest は、なんらかの型 T に関してジヱネリックであ 
ると。この関数には list という引数が1つあり、これは型 T の値のスライスです。 largest 関数は 
同じ T 型の値を返します。 

リスト 10-5 は、シグニチャにジヱネリックなデータ型を使用して largest 関数定義を組み合わせ 
たものを示しています。このリストはさらに、この関数を i 32 値か char 値のどちらかで呼べる方法 
も表示しています。このコードはまだコンパイルできないことに注意してください。ですが、この章 
の後ほど修正します。 

フアイル名： src / main.rs 

fn largest く T >( list : & [ T ]) - > T { 

let mut largest = list [0]; 

for &item in list . iter () { 
if item > largest { 
largest = item ; 

} 

} 

largest 

} 

fn main () { 

let number_list = vec ! [34, 50， 25，100， 65]; 

let result = largest (& number _ list ); 

println! ("The largest number is {}" , result ); 

let char 一 list = vec ! [' y ', ' m ', ' a ', ' q ']; 

let result = largest (& char _ list ); 

println! ("The largest char is {}" , result ); 

} 

リスト 10-5: ジヱネリックな型引数を使用するものの、まだコンパイルできない largest 関数の 
定義 

直ちにこのコードをコンパイルしたら、以下のようなエラーが出ます： 

error *[ E 0369] : binary ooeration > cannot be applied to tvpe T 

(エラー： 2 項演算 '〉' は、型、 T' に適用できません） 

-- > src / main . rs :5:12 
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5 | 1 f item > largest { 

| 八八八八八八八八八八八八八八 

I 

= note : an implementation of ' std :: cmp :: PartialOrd ' might be missing for ' T ' 

( 注釈： ' std : : cmp : : Parti alOrd ' の実装が ' T ' に対して存在しない可能性があります） 

注釈が std : : cmp : : PartialOrd に触れていて、これは、トレイトです。トレイトについては、次 
の節で語ります。とりあえず、このエラーは、 largest の本体は、 T がなりうる全ての可能性のあ 
る型に対して動作しないと述べています。本体で型 T の値を比較したいので、値が順序付け可能 
な型のみしか使用できないのです。比較を可能にするために、標準ライブラリには型に実装できる 
std : : cmp : : PartialOrd トレイトがあります（このトレイトについて詳しくは付録 C を参照されたし)。 
ジェネリックな型が特定のトレイトを持つと指定する方法は「トレイト境界」節で習うでしょうが、 
先にジェネリックな型引数を使用する他の方法を探究しましょう。 

10.2.2 構造体定義では 

また、構造体を定義して<> 記法で1つ以上のフィールドにジェネリックな型引数を使用することも 
できます。リスト 10-6 は、 Point < T > 構造体を定義してあらゆる型の x と y 座標を保持する方法を示 
しています。 

フ アイ ル名： src / main.rs 

struct Point く T > { 
x : T , 
y : T , 

} 

fn mann () { 

let integer = Point { x : 5, y : 10 }; 
let float = Point { x :1.0, y : 4.0 }; 

} 

リスト 10-6: 型 T の x と y 値を保持する Point く T > 構造体 

構造体定義でジヱネリクスを使用する記法は、関数定義のものと似ています。まず、山カッコ内に 
型引数の名前を構造体名の直後に宣言します。そして、そうしていなければ具体的なデータ型を記述 
する構造体定義の箇所にジェネリックな型を使用できます。 

1つのジヱネリックな型だけを使用して Point < T > を定義したので、この定義は、 Point < T > 構造体 
がなんらかの型 T に関して、ジェネリックであると述べていて、その型がなんであれ、 x と y のフィー 
ルドは両方その同じ型になっていることに注意してください。リスト 10-7 のように、異なる型の値 
のある Point < T > のインスタンスを生成すれば、コードはコンパイルできません。 
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フアイル名： src / mam.rs 

struct Point く T > { 
x : T , 
y : T , 

} 

rn main () { 

let wont_work = Point { x : 5, y : 4.0 }; 

} 


リスト 10-7: どちらも同じジェネリックなデータ型 T なので、 x と y というフイールドは同じ型で 
なければならない 


この例で、 x に整数値5を代入すると、この Point < T > のインスタンスに対するジヱネリックな型 T 
は整数になるとコンパイラに知らせます。それから y に 4.0 を指定する時に、このフィールドは x と 
同じ型と定義したはずなので、このように型不一致エラーが出ます： 


error [ E 0308] : mismatched types 
——> src / main • rs :7:38 


7 | let wont_work = 

I 

floating-point variable 


Point { x : 5， y : 4.0 }; 

aaa expected integral variable , found 


= note : expected type ' nteger } 
found type '{ float }' 


x と y が両方ジヱネリックだけれども、異なる型になり得る Point 構造体を定義するには、複数の 
ジェネリックな型引数を使用できます。例えば、リスト 10-8 では、 Point の定義を変更して、型丁と 
U に関してジヱネリックにし、 x が型 T で、 y が型 U になります。 

フアイル名： src / main.rs 

struct Point < T , U > { 
x : T , 
y : U , 

} 

fn main () { 

let both_integer = Point { x : 5, y : 10 }; 
let both_float = Point { x : 1.0, y : 4.0 }; 
let integer _ and_float = Point { x : 5, y : 4.0 }; 

} 


リスト 10-8: Point く T , U > は 2 つの型に関してジェネリックなので、 x と y は異なる型の値になり 
得る 
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もう、示された Point インスタンスは全部許可されます！所望の数だけ定義でジヱネリックな型 
引数を使用できますが、数個以上使用すると、コードが読みづらくなります。コードで多くのジェネ 
リックな型が必要な時は、コードの小分けが必要なサインかもしれません。 

10.2 .3 enum 定義では 

構造体のように、列挙子にジェネリックなデータ型を保持する enum を定義することができます。 
標準ライブラリが提供している o P tion < T > enum に別の見方をしましょう。この enum は第 6 章で 
使用しました： 

enum Option < T > { 

Some ( T ) ， 

None , 

} 

この定義はもう、あなたにとってより道理が通っているはずです。ご覧の通り、 Option < T > は、型 T 
に関してジェネリックで 2 つの列挙子のある enum です：その列挙子は、型 t の値を保持する some 
と、値を何も保持しない None です 〇 Option < T > enum を使用することで、オプショナルな値がある 
という抽象的な概念を表現でき、 Option < T > はジェネリックなので、オプショナルな値の型に関わら 
ず、この抽象を使用できます。 

enum も複数のジェネリックな型を使用できます。第9章で使用した Result enum の定義が一例 
です： 


enum Result < T , E > { 
Ok ( T ), 

Err ( E ), 


Result enum は 2 つの型 t 、 e に関してジェネリックで、 2 つの列挙子があります：型 t の値を保 
持する Ok と、型 E の値を保持する Err です。この定義により、 Result enum を成功する（なんらか 
の型 T の値を返す）か、失敗する（なんらかの型 E のエラーを返す）可能性のある処理があるあらゆる 
箇所に使用するのが便利になります。事実、ファイルを開くのに成功した時に T に型 std :: fs::File 
が入り、ファイルを開く際に問題があった時に E に型 std :: io :: Error が入ったものが、リスト 9-3 
でファイルを開くのに使用したものです。 

自分のコード内で、保持している値の型のみが異なる構造体や enum 定義の場面を認識したら、代 
わりにジェネリックな型を使用することで重複を避けることができます。 

10.2 .4 メソッド定義では 

(第5章のように、）定義にジヱネリックな型を使うメソッドを構造体や enum に実装することも 
できます。リスト 10-9 は、リスト 10-6 で定義した Point < T > 構造体に x というメソッドを実装した 
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ものを示しています。 

フアイル名： src / main.rs 

struct Point く T > { 
x : T , 
y : T , 

} 

impl く T > Point く T > { 

fn x (& self ) -> &T { 

& self .x 

} 

} 

fn main () { 

let p = Point { x : 5, y :10 }; 
println ! ( n p .x = {}"， p . x ()); 

} 

リスト 10-9: 型 T の x フィールドへの参照を返す x というメソッドを Point く T > 構造体に実装する 

ここで、フィールド x のデータへの参照を返す x というメソッドを Point < T > に定義しました。 

型 Poi _ nt < T > にメソッドを実装していると指定するために T を使用できるよう impt の直後に宣言 
しなければならないことに注意してください。 impl の後に T をジェネリックな型として宣言すること 
で、コンパイラは、 Point の山カッコ内の型が、具体的な型ではなくジヱネリックな型であることを 
認識できるのです。 

例えば、あらゆるジヱネリックな型とともに Point < T > インスタンスではなく、 Point < f 32> だけに 
メソッドを実装することもできるでしょう。リスト 10-10 では、具体的な型 f 32 を使用しています。 
つまり、 impl の後に型を宣言しません。 

# struct Point く T > { 

# x : T , 

# y ： T , 

# } 

# 

impl Point < f 32> { 

fn distance _ from _ origin (& self ) -> f 32 { 

( self . x . powi (2) + self . y . powi (2)). sqrt () 



リスト 10-10： ジェネリックな型引数 T に対して特定の具体的な型がある構造体にのみ適用される 
impl ブロック 

このコードは 、 Point く f 32> には di stance_f ronuorigin というメソッドが存在するが、 T が f 32 で 
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はない Point < T > の他のインスタンスにはこのメソッドが定義されないことを意味します。このメ 
ソッドは、この点が座標 (0.0, 0.0) の点からどれだけ離れているかを測定し、浮動小数点数にのみ利 
用可能な数学的処理を使用します。 

構造体定義のジヱネリックな型引数は、必ずしもその構造体のメソッドシグニチャで使用するもの 
と同じにはなりません。例を挙げれば、リスト 10-11 は、リスト 10-8 の Point < T , U > にメソッド 
mixup を定義しています。このメソッドは、他の Point を引数として取り、この引数は mixup を呼び 
出している self の Point とは異なる型の可能性があります。このメソッドは、（型 T の) self の Point 
の x 値と渡した（型 W の) Point の y 値から新しい Point インスタンスを生成します。 

フ アイ ル名： src / main.rs 

struct Point < T , U > { 
x : T , 
y : U , 

} 

■ impl < T , U > Point < T , U > { 

fn mixup く V ， W > ( self , other : Point く V ， W >) -> Point < T , W > { 

Point { 

x : self . x , 
y : other . y , 



fn main () { 

let pi=Point { x : 5， y :10.4 }; 

let p 2 = Point { x : " Hello ", y : ' c '}; 

let p 3 = pl . mixup ( p 2); 

println ! (" p 3 .x = {}， p 3 .y = {}"， p 3. x , p 3. y ); 

} 

リスト 10-11: 構造体定義とは異なるジェネリックな型を使用するメソッド 

main で 、 x (値は5 ) に i 32 、 y (値は10.4 ) に f 64 を持つ Point を定義しました。 p 2 変数は 、 x (値 
は" HelAo ") に文字列スライス 、 y (値は c ) に char を持つ Poi nt 構造体です。引数 p 2 で pi に mixup 
を呼び出すと、 p 3 が得られ、 x は132になります。 x は pi 由来だからです。 p 3 変数の y は、 char に 
なります。 y は p 2 由来だからです。 pn ' ntln ! マクロの呼び出しは、 p 3 .x = 5, p 3 .y = c と出力する 
でしよう。 

この例の目的は、一部のジヱネリックな引数は impl で宣言され、他の一部はメソッド定義で宣言 
される場面をデモすることです。ここで、ジヱネリックな引数 T と U は impt の後に宣言されていま 
す。構造体定義にはまるからです。ジェネリックな引数 V と W は fn mixup の後に宣言されています。 
何故なら、このメソッドにしか関係ないからです。 
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10.2 .5 ジェネリクスを使用したコードのパフォーマンス 

ジェネリックな型引数を使用すると、実行時にコストが発生するかあなたは不思議に思っている可 
能性があります。コンパイラが、ジェネリクスを具体的な型がある時よりもジェネリックな型を使用 
したコードを実行するのが遅くならないように実装しているのは、嬉しいお知らせです。 

コンパイラはこれをジヱネリクスを使用しているコードの単相化をコンパイル時に行うことで達成 
しています。 単相化 （ monomorphization) は、コンパイル時に使用されている具体的な型を入れる 
ことで、ジヱネリックなコードを特定のコードに変換する過程のことです。 

この過程において、コンパイラは、リスト 10-5 でジェネリックな関数を生成するために使用した 
手順と真逆のことをしています：コンパイラは、ジェネリックなコードが呼び出されている箇所全部 
を見て、ジェネリックなコードが呼び出されている具体的な型のコードを生成するのです。 

標準ライブラリの option < T > enum を使用する例でこれが動作する方法を見ましょう： 

let integer = Some (5) ; 

let float = Some (5.0); 

コンパイラがこのコードをコンパイルすると、単相化を行います。その過程で、コンパイラは 
Option < T > のインスタンスに使用された値を読み取り、2種類の Option < T > を識別します：一方は i 32 
で、もう片方は f 64 です。そのように、コンパイラは、 Opti on < T > のジヱネリックな定義を Opti on _ i 32 
と 0 ption _ f 64 に展開し、それにより、ジヱネリックな定義を特定の定義と置き換えます。 

単相化されたバージョンのコードは、以下のようになります。ジヱネリックな Option < T > が、コン 
パイラが生成した特定の定義に置き換えられています： 

フアイル名： src/main.rs 

enum 0 ption _ i 32 { 

Some ( i 32) ， 

None , 

} 

enum 0 ption _ t 64 { 

Some ( f 64) ， 

None , 

} 

fn mai . n () { 

let integer = Option _ i 32 :: Some (5); 
let float = 0 ption _ f 64: : Some (5.0) ; 

} 


Rust では、ジェネリックなコードを各インスタンスで型を指定したコードにコンパイルするので、 
ジェネリクスを使用することに対して実行時コストを払うことはありません。コードを実行すると、 
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それぞれの定義を手作業で複製した時のように振る舞います。単相化の過程により、 Rust のジヱネリ 
クスは実行時に究極的に効率的になるのです。 

10.3 トレイト：共通の振る舞いを定義する 

トレイトにより、 Rust コンパイラに特定の型に存在し、他の型と共有できる機能について知らせ 
ます。トレイトを使用して共通の振る舞いを抽象的に定義できます。トレイト境界を使用して、ある 
ジェネリックが特定の振る舞いのあるあらゆる型になり得ることを指定できます。 

注釈：違いはあるものの、トレイトは他の言語でよくインターフヱイスと呼ばれる機能に類似 
しています。 

10.3.1 トレイトを定義する 

型の振る舞いは、その型に対して呼び出せるメソッドから構成されます。異なる型は、それらの型 
全部に対して同じメソッドを呼び出せたら、同じ振る舞いを共有します。トレイト定義は、メソッド 
シグニチヤを一緒くたにしてなんらかの目的を達成するのに必要な一連の振る舞いを定義する手段 
です。 

例えば、いろんな種類や量のテキストを保持する複数の構造体があるとしましょう：特定の場所で 
送られる新しいニュースを保持する NewsArticle と、新規ツイートか、リツイートか、はたまた他の 
ツイートへのリプライなのかを示すメタデータを伴う最大で280文字までの Tweet です。 

NewsArticle または Tweet インスタンスに保存されているデータのサマリを表示できるメディアア 
グリゲータライブラリを作成します。これをするには、各型のサマリーが必要で、インスタンスで 
summarize メソッドを呼び出してサマリーを要求する必要があります。リスト 10-12 は、この振る舞 
いを表現する Summary トレイトの定義を表示しています。 

ファイル名： src / lib.rs 

pub trait Summary { 

fn summarize (& self ) -> String ; 

} 

リスト 10-12: summarize メソツドで提供される振る舞いからなる Summary トレイト 

ここでは、 trait キーワード、それからトレイト名を使用してトレイトを定義していて、その名前 
は今回の場合、 Summary です。波括弧の中にこのトレイトを実装する型の振る舞いを記述するメソッ 
ドシグニチヤを定義し、今回の場合は、 fn summarize (& self ) -> String です。 

メソッドシグニチヤの後に、波括弧内に実装を提供する代わりに、セミコロンを使用しています。 
このトレイトを実装する型はそれぞれ、メソッドの本体に独自の振る舞いを提供しなければなりま 
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せん。コンパイラにより、 Summary トレイトを保持するあらゆる型に、このシグニチャと全く同じメ 
ソッド summarize が定義されていることが、強制されます。 

トレイトには、本体に複数のメソッドを含むことができます：メソッドシグニチャは行ごとに列挙 
され、各行はセミコロンで終止します。 

10.3.2 トレイトを型に実装する 

今や Summary トレイトを使用して目的の動作を定義できたので、メディアアグリゲータで型に実装 
できます。リスト 10-13 は、 Summary トレイトを NewsArticle 構造体上に実装したもので、ヘッドラ 
イン、著者、そして Summarize の民り値を示しています。 Tweet 構造体に関しては、ツイートの内容 
が既に280文字に制限されていると仮定して、ユーザー名の後にツイートのテキスト全体が続くもの 
として Summarize を定義します。 

ファイル名： src / lib.rs 

# pub trait Summary i 

# fn summari ze (& self ) -> String ; 

# } 

# 

pub struct NewsArticle { 
pub headline : String , 
pub location : String , 
pub author : String , 
pub content : String , 

} 

impl Summary for NewsArticle { 

fn summarize (& self ) -> String { 

format ! ("{} , by {} ({})", self . headline , self . author , self . location ) 



pub struct rweet { 

pub username : String , 
pub content : Stri ng , 
pub reply : bool , 
pub retweet : bool , 

} 


impl Summary for iweet { 

fn summari ze (& self ) -> String { 

format ! ("{} : {}" , self . username , self . content ) 



リスト 10-13: Summary トレイトを NewsArti cle と Tweet 型に実装する 
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型にトレイトを実装することは、普通のメソッドを実装することに似ています。違いは、 impl の後 
に、実装したいトレイトの名前を置き、それから for •キーワード、さらにトレイトの実装対象の型の 
名前を指定することです。 impl ブロック内に、トレイト定義で定義したメソッドシグニチャを置きま 
す。各シグニチャの後にセミコロンを追記するのではなく、波括弧を使用し、メソッド本体に特定の 
型のトレイトのメソッドに欲しい特定の振る舞いを入れます。 

トレイトを実装後、普通のメソッド同様に NewsArti cle や Tweet のインスタンスに対してこのメ 
ソッドを呼び出せます。こんな感じで： 

let tweet = Tweet { 

username : String : : f rom (" horse _ ebooks ") , 

// もちろん、ご存知かもしれないようにね、みなさん 

content : String : : from( n of course , as you probably already know , people ") , 
reply : false , 
retweet : false , 

}； 

println ! ("1 new tweet : {}" , tweet • summarize ()); 

この ー ド从、 1 new tweet : horse_ebooks : of course , as you probably already know , 
people と出力します。 

リスト 10-13 で Summary トレイトと NewArti cle , Tweet 型を同じ lib . FS に定義したので、全部 
同じスコープにあることに注目してください。この lib . rs を aggregator と呼ばれるクレート専用に 
して、誰か他の人が私たちのクレートの機能を活用して自分のライブラリのスコープに定義された構 
造体に Summary トレイトを実装したいとしましょう。まず、トレイトをスコープにインポートする 
必要があるでしょう。 use aggregator : : Summary ; と指定してそれを行い、これにより、自分の型に 
Summary を実装することが可能になるでしょう。 Summary トレイトは、他のクレートが実装するため 
には、公開トレイトである必要があり、ここでは、リスト 10-12 の trait の前に、 pub キーワードを 
置いたのでそうなっています。 

トレイト実装で注意すべき制限の1つは、トレイトか対象の型が自分のクレートに固有 （ local ) で 
ある時のみ、型に対してトレイトを実装できるということです。例えば、 Display のような標準ライ 
ブラリのトレイトを aggregator クレートの機能の一部として、 Tweet のような独自の型に実装でき 
ます。型 Tweet が aggregator クレートに固有だからです。また、 Summary を aggregator クレートで 
Vec < T > に対して実装することもできます。トレイト Summary は、 aggregator クレートに固有だから 
です。 

しかし、外部のトレイトを外部の型に対して実装することはできません。例として、 aggregator ク 
レート内で Vec < T > に対して Display トレイトを実装することはできません。 Di splay と Vec < T > は標 
準ライブラリで定義され、 aggregator クレートに固有ではないからです。この制限は、コヒーレンス 
( coherence ) あるいは、具体的に才ーファンルール （orphan rule ) と呼ばれるプログラムの特性の 
一部で、親の型が存在しないためにそう命名されました。この規則により、他の人のコードが自分の 
コードを壊したり、その逆が起きないことを保証してくれます。この規則がなければ、2つのクレー 
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卜が同じ型に対して同じトレイトを実装できてしまい、コンパイラはどちらの実装を使うべきかわか 
らなくなってしまうでしよう。 


10.3.3 デフォルト実装 

時として、全ての型の全メソッドに対して実装を必要とするのではなく、トレイトの全てあるいは 
一部のメソッドに対してデフォルトの振る舞いがあると有用です。そうすれば、特定の型にトレイト 
を実装する際、各メソッドのデフォルト実装を保持するかオーバーライドできるわけです。 

リスト 10-14 は、リスト 10-12 のように、メソッドシグニチヤだけを定義するのではなく、 Summary 
トレイトの summarize メソッドにデフォルトの文字列を指定する方法を示しています： 

ファイル名： src / lib.rs 

pub trait Summary { 

fn summarize(&self) -> String { 

// ( もっと読む） 

Stri ng: : from(" (Read more...) ") 



リスト 10-14: summari ze メソッドのデフオルト実装がある Su 麵 ary トレイトの定義 

独自の実装を定義するのではなく、デフォルト実装を使用して NewsArticle のインスタンスをまと 
めるには、 impl Summary for NewsArticle {} と空の impl ブロックを指定します 0 
たとえ、最早 NewsArticle に直接 summarize メソッドを定義することはなくても、デフオルト実 
装を提供し、 NewsArticle は Summary トレイトを実装すると指定しました。結果的に、それでも、 
NewsArticle のインスタンスに対して summarize メソッドを呼び出すことができます。このように： 

let article = NewsArticle i 

II ペンギンチームがスタンレーカップチャンピオンシップを勝ち取る！ 

headline: String: : f rom("Penguins win the Stanley Cup Championship!"), 

// ピッツバーグ、ペンシルベニア州、アメリカ 
location : String: : from ("Pittsburgh, PA, USA") , 

// アイスバーグ 

author : Stri ng: : f rom("Iceburgh") , 

// ピッツバーグ.ペンギンが再度 NHL (National Hockey League) で最強のホッケー 
チームになった 

content : String: : from("The Pittsburgh Penguins once again are the best 
hockey team in the NHL. ") , 

}； 


// 新しい記事が利用可能です！ {} 

println ! ("New article available! {}" , article.summarize()); 

このコ^ ー ドは、 New article available! (Read more...) と出力します 0 
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summarize にデフオルト実装を用意しても、リスト 10-13 の Tweet の Summary 実装を変える必要 
はありません。理由は、デフォルト実装をオーバーライドする記法がデフォルト実装のないトレイト 
メソッドを実装する記法と同じだからです。 

デフォルト実装は、他のデフォルト実装がないメソッドでも呼び出すことができます。このように、 
トレイトは多くの有用な機能を提供しつつ、実装者に僅かな部分だけ指定してもらう必要しかないの 
です。例えば、 Summary トレイトを実装が必須の summarize_author メソッドを持つように定義し、そ 
れから summaHze_author •メソッドを呼び出すデフオルト実装のある summarize メソッドを定義する 
こともできます： 


pub trait nummary { 

fn summanze_author (&self ) -> String; 

fn summarize(&self) -> String { 

// {} さんからもっと読む 

format! (" (Read more from self .summarize_author()) 



このバージヨンの Summary を使用するには、型にトレイトを実装する際に summarize_author を定 
義する必要しかありません： 


impl Summary tor Tweet { 

fn summarize_author (&self ) -> String { 
format! ("@{} u , self .username) 

} 

} 

summaHze_author 定義後、 Tweet 構造体のインスタンスに対して summarize を呼び出せ、 summarize 
のデフオルト実装は、提供済みの summarize_author の定義を呼び出すでしよう。 summarize_author 
を実装したので、追加のコードを書く必要なく、 Summary トレイトは、 summarize メソッドの振る舞 
いを与えてくれました。 

Let tweet = Tweet { 

username : String: : f rom("horse_ebooks") , 

content : String: : from("of course, as you probably already know, people") , 
reply : false, 
retweet: false, 

}； 


println! ("1 new tweet : {}" , tweet•summarize()); 

このコードは、 1 new tweet : (Read more from @horse_ebooks...) と出力します。 

同じメソッドのオーバーライドした実装からは、デフォルト実装を呼び出すことができないことに 
注意してください。 
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10.3.4 トレイト境界 

これでトレイトの定義とトレイトを型に実装する方法を知ったので、ジヱネリックな型引数でトレ 
イトを使用する方法を探究できます。トレイト境界を使用してジェネリックな型を制限し、型が特定 
のトレイトや振る舞いを実装するものに制限されることを保証できます。 

例として、リスト10 -13 で、 Summary トレイトを型 NewsArticle と Tweet に実装しました。引数 
item に対して summarize メソッドを呼び出す関数 notify を定義でき、この引数はジヱネリックな 
型 T です。ジェネリックな型 T がメソッド summarize を実装しないというエラーを出さずに item に 
summarize を呼び出せるために、 T に対してトレイト境界を使用して ' i tem は、 Summary トレイトを実 
装する型でなければならないと指定できます： 

oub rn noti ry < T : Summary > (. item : T ) { 

// 新ニュース！ {} 

println ! ("Breaking news ! {}" , 1 ’ tem . summarize ()); 

} 

トレイト境界をジェネリックな型引数宣言とともにコロンの後、山カッコ内に配置しています 。 T 
に対するトレイト境界のため 、 noti fy を呼び出して NewsArticle か Tweet のどんなイ ンスタンス 
も渡すことができます。あらゆる他の型、 String や i 32 などでこの関数を呼び出すコードは、型が 
Sugary を実装しないので、コンパイ ルで きません。 

+記法でジェネリックな型に対して複数のトレイト境界を指定できます。例えば、関数で T に対し 
てフォーマツト表不と 、 summarize メソツドを使用するには、 T : Summary + Display を使用して 、 T 
は Summary と Display を実装するどんな型にもなると宣言できます。 

しかしながら、トレイト境界が多すぎると欠点もあります。各ジェネリックには、特有のトレイト 
境界があるので、複数のジェネリックな型引数がある関数には、関数名と引数リストの間に多くの卜 
レイト境界の情報が付くこともあり、関数シグニチヤが読みづらくなる原因になります。このため、 
Rust には関数シグニチヤの後、 where 節内にトレイト境界を指定する対立的な記法があります。従っ 
て、こう書く代わりに： 

fn some _ function < T : Disolay + Clone , U : Clone + Debug 〉 （ t : T , u : U ) -> i 32 { 

こんな感じに where 節を活用できます： 

fn some _ function < T , U >( t : T , u : U ) -> i 32 
where T : Display + Clone , 

U : Clone + Debug 

{ 

この関数シグニチヤは、多くのトレイト境界のない関数のように、関数名、引数リスト、戻り値の 
型が一緒になって近いという点でごちゃごちゃしていません。 
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10.3.5 トレイト境界で largest 関数を修正する 

ジェネリックな型引数の境界で使用したい振る舞いを指定する方法を知ったので、リスト 10-5 に 
戻って、ジェネリックな型引数を使用する largest 関数の定義を修正しましょう！最後にそのコー 
ドを実行しようとしたら、こんなエラーが出ました： 

error*[E0369] : binary operation > cannot be applied to tvpe T 
--> src/main.rs:5:12 

I 

5 | if item > largest { 

j 八八八八八八八八八八八八八八 

I 

=note : an implementation of 'std: : cmp: : PartialOrd' might be missing for 'T' 

largest の本体で、大なり演算子 （>) を使用して型 T の 2 つの値を比較したかったのです。その演 
算子は、標準ライブラリトレイトの S td ::C mp :: P a rfi a 10rd でデフオルトメソッドとして定義されて 
いるので、 largest 関数が、比較できるあらゆる型のスライスに対して動くように、 T のトレイト境 
界に PartialOrd を指定する必要があります。初期化処理に含まれているので、 PartialOrd をスコー 
プに導入する必要はありません。 largest のシグニチャを以下のような見た目に変えてください： 

fn largest く T: PartialOrd〉 （list : & [T]) -> T { 


今度コードをコンパイルすると、異なる一連のエラーが出ます: 


error [ E 0508] : cannot move out or type [ T ] ， a non-copy slice 
(エラー： '[ 丁]、、コピーでないスライスから ムーブ できません。） 

-- > src / main . rs :2:23 

I 

2 | let mut largest = list [0]; 

I A A A A A A A 

I I 

| cannot move out of here 

| help : consider using a reference instead : '& list [0] 

( 助言：代わりに参照の使用を考慮してください： 

[ 0 ]') 


error[E0507] : cannot move out or borrowed content 
(エラー： 借用された内容からムーブできません） 

-- > src/main.rs :4:9 


4 


for tern in list.iter() { 

II 

|hint: to prevent move, use 'ref item' or 'ref mut item' 
cannot move out of borrowed content 

( ヒント：ムーブを避けるには 、' ref item' か ' ref mut item ' を使用してく 
ださい） 
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この エラー の鍵となる行は 、 cannot move out of type [ T ] , a non-copy slice です。ジヱネリツ 
クでないバージョンの largest 関数では、最大の i 32 か char を探そうとするだけでした。第4章の 
「スタックだけのデータ：コピー」節で議論したように、 i 32 や char のような既知のサイズの型は、 
スタックに格納できるので、 Copy トレイトを実装しています。しかし、 largest 関数をジェネリック 
にすると、 list 引数が Copy トレイトを実装しない型を含む可能性も出てきたのです。結果として、 
list [0] から値を largest に ムーブできず、この エラーに 陥ったのです。 

このコードを Copy トレイトを実装する型とだけで呼び出すには、 T のトレイト境界に Copy を 
追加できます！リスト 10-15 は、関数に渡したスライスの値の型が彳32や char などのように、 
PartialOrd と Copy を実装する限り、コンパイルできるジヱネリックな largest 関数の完全なコード 
を示しています。 

フ アイ ル名： src / main.rs 

fn largest く T : PartialOrd + Copy 〉 （ list : & [ T ]) - > T { 

let mut largest = list [0]; 

for &itern in list . iter () { 
if item > largest { 
largest = item ; 

} 

} 

largest 

} 

fn main () { 

let number_list = vec ! [34, 50， 25，100， 65]; 

let result = largest (& number _ list ); 

println! ("The largest number is {}" , result ); 

let char 一 list = vec ! [' y ', ' m ', ' a ', ' q ']; 

let result = largest (& char _ list ); 

println! ("The largest char is {}" , result ); 

} 

リスト 10-15: Parti alOrd と Copy トレイトを実装するあらゆるジェネリックな型に対して動く、 
largest 関数の動く定義 

もし largest 関数を Copy を実装する型だけに制限したくなかったら、 Copy ではなく、 T が Clone 
というトレイト境界を含むと指定することもできます。そうしたら、 largest 関数に所有権が欲しい 
時にスライスの各値をクローンできます。 clone 関数を使用するということは、 String のようなヒー 
プデータを所有する型の場合にもっとヒープ確保が発生する可能性があることを意味し、大きなデー 
夕を取り扱っていたら、ヒープ確保は遅いこともあります。 
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largest の別の実装方法は、関数がスライスの T 値への参照を返すようにすることです。戻り値の 
型を T ではなく & T に変え、それにより関数の本体を参照を返すように変更したら、 Clone か Copy 卜 
レイト境界は必要なくなり、ヒープ確保も避けられるでしょう。試しにこれらの対立的な解決策もご 
自身で実装してみてください！ 


10.3.6 トレイト境界を使用して、メソッド実装を条件分けする 

impl ブロックでジェネリックな型引数を使用するトレイト境界を活用することで、特定のトレイト 
を実装する型に対するメソッド実装を条件分けできます。例えば、リスト 10-16 の型 Pair < T > は、常 
に new 関数を実装します。しかし、 Pai _ r < T > は、内部の型 T が比較を可能にする PartialOrd トレイト 
と出力を可能にする Display トレイトを実装している時のみ、 cmp_cH splay メソッドを実装します。 

use std :: fmt :: Di splay ; 

struct Pair < T > { 
x : T , 
y : T , 

} 

■impl く T > Pair ■く T > { 

fn new ( x : T , y : T ) -> Self { 

Self { 
x , 
y » 

} 

} 

} 

impl く T : Display + PartialOrd > Pair < T > { 
fn cmp_display (& self ) { 
if self .x >= self .y { 

println! ("The largest member is x = {}" , self . x ); 

} else { 

println! ("The largest member is y = {}" , self . y ); 



リスト 10-16: トレイト境界によってジェネリックな型に対するメソッド実装を条件分けする 

また、別のトレイトを実装するあらゆる型に対するトレイト実装を条件分けすることもできま 
す。トレイト境界を満たすあらゆる型にトレイトを実装することは、ブランケット実装 （blanket 
implementation ) と呼ばれ、 Rust の標準ライブラリで広く使用されています。例を挙げれば、標準 
ライブラリは、 Display トレイトを実装するあらゆる型に ToString トレイトを実装しています。標準 
ライブラリの impl ブロックは以下のような見た目です： 
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]mpl<T: Displav> ToString tor T { 

// --snip__ 

} 

標準ライブラリに はこの ブランケット実装があるので、 Display トレイトを実装する任意の型に 
対して、 ToString トレイトで定義された to_stri_ng メソッドを呼び出せるのです。例えば、整数は 
Display を実装するので、このように整数値を対応する String 値に変換できます： 

Let s = 3 .to_string() ; 

ブランケット実装は、「実装したもの」節のトレイトのドキュメンテーションに出現します。 

トレイトとトレイト境界により、ジェネリックな型引数を使用して重複を減らしつつ、コンパイラ 
に対して、そのジヱネリックな型に特定の振る舞いが欲しいことを指定するコードを書くことができ 
ます。それからコンパイラは、トレイト境界の情報を活用してコードに使用された具体的な型が正し 
い振る舞いを提供しているか確認できます。動的型付け言語では、型が実装しない型のメソッドを呼 
び出せば、実行時にエラーが出るでしょう。しかし、 Rust はこの種のエラーをコンパイル時に移した 
ので、コードが動かせるようにさえなる以前に問題を修正することを強制されるのです。加えて、コ 
ンパイル時に既に確認したので、実行時に振る舞いがあるかどうか確認するコードを書かなくても済 
みます。そうすることでジェネリクスの柔軟性を諦める必要なく、パフォーマンスを向上させます。 

もう使用してきたことのある別の種のジヱネリクスは、ライフタイムと呼ばれます。型が欲しい振 
る舞いを保持していることを保証するのではなく、必要な間だけ参照が有効であることをライフタイ 
ムは保証します。ライフタイムがどうやってそれを行うかを見ましょう。 

10.4ライフタイムで参照を検証する 

第4章の「参照と借用」節で議論しなかった詳細の一つは、 Rust において参照は全てライフタイ 
ムを保持することであり、ライフタイムとは、その参照が有効になるスコープのことです。多くの場 
合、型が推論されるように、多くの場合、ライフタイムも暗黙的に推論されます。複数の型の可能性 
があるときには、型を注釈しなければなりません。同様に、参照のライフタイムがいくつか異なる方 
法で関係することがある場合には注釈しなければなりません。コンパイラは、ジェネリックライフタ 
イム引数を使用して関係を注釈し、実行時に実際の参照が確かに有効であることを保証することを要 
求するのです。 

ライフタイムの概念は、他のプログラミング言語の道具とはどこか異なり、議論はあるでしょうが、 
ライフタイムが Rust で一番際立った機能になっています。この章では、ライフタイムの全てを講義 
しないものの、ライフタイム記法と遭遇する可能性のある一般的な手段を議論するので、概念に馴染 
めます。もっと詳しく知るには、第19章の「高度なライフタイム」節を参照されたし。 
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10.4.1 ライフタイムでダングリング参照を回避する 

ライフタイムの主な目的は、ダングリング参照を回避することであり、ダングリング参照によりプ 
ログラムは、参照することを意図したデータ以外のデータを参照してしまいます。リスト 10-17 のプ 
ログラムを考えてください。これには、外側のスコープと内側のスコープが含まれています。 

{ 

let r; 

{ 

let x = 5; 
r = &x; 

} 

println! ("r: {}", r); 

} 

リスト 10-17: 値がスコープを抜けてしまった参照を使用しようとする 

注釈：リスト 10-17 や10-18、 10-24 では、変数に初期値を与えずに宣言しているので、変数 
名は外側のスコープに存在します。初見では、これは Rust には null 値が存在しないというこ 
とと衝突しているように見える可能性があります。しかしながら、値を与える前に変数を使用 
しようとすれば、 コンパイル エラーになり、確かに Rust では null 値は許可されないことを示 
します。 


外側の スコープで 初期値なしの r という変数を宣言し、内側の スコープで 初期値5の X という変数 
を宣言しています。内側の スコープ 内で、 r の値を X への参照に セットし ようとしています。それか 
ら内側の スコープが 終わり、 r の値を出力しようとしています。 r が参照している値が使おうとする 
前に スコープを 抜けるので、この コードはコンパイルで きません。こちらが エラーメッセージです： 


error[E0597] : x does not live Long enough 

( エラー： 'x' の生存期間が短すぎます） 

-- > src/main.rs:7:5 


6 


r = &x; 

- borrow occurs here 

( 借用はここで起きています） 

} 

a 'x' dropped here while still borrowed 

(' x' は借用されている間にここでド ロッ プされました） 


10 


- borrowed value needs to live until here 

( 借用された値はここまで生きる必要があります） 




第 10 章ジェネリック型、トレイト、ライフタイム 


205 


変数 X の「生存期間が短すぎます。」原因は内側のスコープが7行目で終わった時点で X がスコー 
プを抜けるからです。ですが、 r はまだ、外側のスコープに対して有効です；スコープが大きいので、 
「長生きする」と言います。 Rust で、このコードが動くことを許可していたら、 r は x がスコープを 
抜けた時に解放されるメモリを参照していることになり、 r で行おうとするいかなることもちゃんと 
動かないでしょう。では、どうやって コンパイ ラはこのコードが無効であると決定しているのでしょ 
うか？借用チヱッカーを使用しています。 

10.4.2 借用精査機 

Rust コンパイラには、スコープを比較して全ての借用が有効であるかを決定する 借用チェッカー 
があります。リスト 10-18 は、リスト 10-17 と同じコードを示していますが、変数のライフタイムを 
表示する注釈が付いています： 

{ 

let r ; //-+ -- ' a 

// | 

{ // | 

let x = 5; // -+-- ’b | 

r = & x ; "I | 

} // -+ | 

// | 

println ! (" r : {}", r ); // | 

} // -+ 

リスト 10-18: それぞれ ' a と ' b と名付けられた r と x のライフタイムの注釈 

ここで、 r のライフタイムは ' a 、 x のライフタイムは ' b で注釈しました。ご覧の通り、内側の 1 b ブ 
ロックの方が、外側の 1 a ライフタイムブロックよりはるかに小さいです。コンパイル時に、コンパイ 
ラは2つのライフタイムのサイズを比較し、 r は ' a のライフタイムだけれども、 ' b のライフタイム 
のメモリを参照していると確認します。 ' b は ' a よりも短いので、プログラムは拒否されます：参照の 
被写体が参照ほど長生きしないのです。 

リスト 10-19 で コードを 修正したので、ダングリング参照はなくなり、 エラーな く コンパイル でき 
ます。 

{ 


let x = 5; 

// - 

- +-- 

'b 


// 

1 


let r = & x ; 

// 

'a | 



// 1 

i 


println ! (" r : {}", 

「）； // 1 

i 



// —+ 

1 



// - 

- + 



リスト 10-19: データのライフタイムが参照より長いので、有効な参照 
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ここで X のライフタイムは 'b になり、今回の場合 1 a よりも大きいです。つまり、コンパイラは X が 
有効な間、 r の参照も常に有効になることを把握しているので、 r は x を参照できます。 

今や、参照のライフタイムがどこにあり、コンパイラがライフタイムを解析して参照が常に有効で 
あることを保証する仕組みがわかったので、関数の文脈でジェネリックな引数と戻り値のライフタイ 
ムを探究しましょう。 

10.4.3 関数のジェネリックなライフタイム 

2つの文字列スライスのうち、長い方を返す関数を書きましょう。この関数は、2つの文字列スラ 
イスを取り、1つの文字列スライスを返します。 longest 関数の実装完了後、リスト 10-20 のコード 
は 、 The logest string is abed と出力するはずです。 

フアイル名： src / main.rs 

fn mann () { 

let stringl = String : : f rom (" abcd ") ; 
let string 2 = " xyz " ; 


let result = longest ( stringl . as _ str (), string 2); 

// 最長の文字列は、です 

println! ("The longest string is {}" , result ); 

} 

リスト 10-20: longest 関数を呼び出して 2 つの文字列スライスのうち長い方を探す main 関数 

関数に取ってほしい引数が文字列スライス、つまり参照であることに注意してください。何故な 
ら、 longest 関数に引数の所有権を奪ってほしくないからです。この関数に String のスライス（変数 
stringl に格納されている型）と文字列リテラル（変数 string 2 が含むもの）を受け取らせたいのです。 

リスト 10-20 で使用している弓 I 数が求めているものである理由についてもっと詳しい議論は、第4 
章の「引数としての文字列スライス」節をご参照ください。 

リスト 10-21 に示したように longest 関数を実装しようとしたら、コンパイルできないでしょう。 

フアイル名： src / main.rs 

fn longest ( x : & str , y : & str ) -> &str { 
if x . len () > y . len () { 


} else { 

y 

} 

} 


リスト 10-21： 2 つの文字列スライスのうち長い方を返すけれども、コンパイルできない longest 
関数の実装 
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代わりに、以下のようなライフタイムに言及するエラーが出ます： 

error [ E 010 6] : missing lifetime specifier 
( エラー： ライフタイム指定子が不足しています） 

-- > src / mann . rs :1:33 

I 

1 | fn longest ( x : & str , y : & str ) -> &str { 

| a expected liretime parameter 

| ( ライフタイム引数が予想されます） 

I 

= heLp : this function's return type contains a borrowed value , but the 
signature does not say whether it is borrowed from ' x ' or ' y ' 

( 助言：この関数の戻り値型は借用された値を含んでいますが、 

シグニチヤは、それが、 x' か、 y' 由来のものなのか宣言していません） 

助言テキストが戻り値の型はジェネリックなライフタイム引数である必要があると明かしていま 
す。というのも、返している参照が x か y を参照しているかコンパイラにはわからないからです。こ 
の関数の本体の if ブロックは x への参照を返し、 else ブロックは y への参照を返すので、実際、ビ 
ちらか私たちにもわかりません！ 

この関数を定義する際、この関数に渡される具体的な値がわからないので、 if ケースか、 else ケー 
スが実行されるか、わからないのです。また、渡される参照の具体的なライフタイムもわからないの 
で、リスト 10-18 と 10-19 で、返す参照が常に有効であるかを決定したようにスコープを見ること 
もできないのです。借用チェッカーもこれを決定することはできません。 x と y のライフタイムがど 
う戻り値のライフタイムと関係するかわからないからです。このエラーを修正するには、借用チェッ 
カーが解析を実行できるように、参照間の関係を定義するジェネリックなライフタイム引数を追加し 
ます。 


10.4.4 ライフタイム注釈記法 

ライフタイム注釈は、いかなる参照の生存期間も変えることはありません。シグニチャがジヱネ 
リックな型引数を指定している時に、関数があらゆる型を受け入れるのと全く同様に、ジェネリック 
なライフタイム引数を指定することで関数は、あらゆるライフタイムの参照を受け入れるのです。ラ 
イフタイム注釈は、ライフタイムに影響することなく、複数の参照のライフタイムのお互いの関係を 
記述します。 

ライフタイム注釈は、少しだけ不自然な記法です：ライフタイム引数の名前はアポストロフィー （' 
) で始まらなければならず、通常全部小文字で、ジェネリック型のようにとても短いです。多くの人 
は、 ' a という名前を使います。ライフタイム引数注釈は、参照の&の後に配置し、注釈と参照の型を 
区別するために空白を1つ使用します。 

例を挙げましょう：ライフタイム引数なしの132への参照、 ' a というライフタイム引数付きの i 32 
への参照、これもライフタイム ' a 付き i 32 への可変参照です。 


// ( ただの）参照 
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&i32 // a rererence 

//明示的なライフタイム付きの参照 
&'a i32 // a rererence with an explicit lifetime 

// 明示的なライフタイム付きの可変参照 
&'a mut i 32 // a mutable reference with an explicit lifetime 

l つのライフタイム注釈それだけでは、大して意味はありません。注釈は、複数の参照のジヱネリッ 
クなライフタイム引数が、お互いにどう関係するかをコンパイラに指示することを意図しているから 
です。例えば、ライフタイム 'a 付きの i32 への 参照となる引数 first のある関数があるとしましょ 
う。この関数にはさらに、 'a のライフタイム付きの i32 への 別の参照となる second という別の引数 
もあります。ライフタイム注釈は、 f i rst と second の参照がどちらもジヱネリックなライフタイムと 
同じだけ生きることを示唆します。 

10.4.5 関数シグニチャにおけるライフタイム注釈 

さて、 longest 関数の文脈でライフタイム注釈を調査しましょう。ジヱネリックな型引数同様、関 
数名と引数リストの間、山カッコの中にジェネリックなライフタイム引数を宣言する必要があります。 
このシグニチャで表現したい制約は、引数の全参照と戻り値が同じライフタイムになることです。ラ 
イフタイムを 'a と名付け、それから各参照に追記します。リスト 10-22 に示したように。 

フアイル名： src / main.rs 

fn longest<'a>(x : &'a str , y : &'a str) -> &'a str { 
if x.len() > y.len() { 


} else { 

y 

} 

} 

リスト 10-22 ： シグニチヤの全参照が同じライフタイム 'a になると指定した longest 関数の定義 

このコードはコンパイル でき、 リスト 10-20 の main 関数とともに使用したら、欲しい結果になる 
はずです。 

これで関数シグニチヤは、何らかのライフタイム4に対して、関数は2つの引数を取り、どちらも 
少なくともライフタイム ' a と同じだけ生きる文字列スライスであるとコンパイラに教えるようになり 
ました。また、この関数シグニチヤは、関数から返る文字列スライスも少なくともライフタイム4と 
同じだけ生きると、コンパイラに教えています。これらの制約は、コンパイラに強制してほしいもの 
です。この関数シグニチヤでライフタイム引数を指定する時、渡されたり、返したりしたいかなる値 
のライフタイムも変更していないことを思い出してください。むしろ、借用チヱツカーは、これらの 
制約を支持しない値全てを拒否するべきと指定しています。 longest 関数は、正確に x と y の生存期 
間を知る必要はなく、何かのスコープが ' a に代替され、このシグニチヤを満足することだけ知ってい 
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る必要があることに注意してください。 

関数でライフタイムを注釈する際、注釈は関数シグニチャに嵌（はま）り、関数本体には嵌りませ 
ん。コンパイラは、なんの助けもなく、関数内のコードを解析できます。しかしながら、関数に関数 
外やからの参照がある場合、コンパイラは引数や戻り値のライフタイムをそれだけではじき出すこと 
はほとんど不可能になります。ライフタイムは、関数が呼び出される度に異なる可能性があります。 
このために、手動でライフタイムを注釈する必要があるのです。 

具体的な参照を longest に渡すと、 ’a を代替する具体的なライフタイムは、 y の スコープと 被さる 
x の スコープの 一部になります。言い換えると、ジェネリックなライフタイム ' a は 、 x と y のライフ 
タイムのうち、小さい方に等しい具体的なライフタイムになるのです。返却される参照を同じライフ 
タイム引数 ' a で注釈したので、返却される参照も x か y のライフタイムの小さい方と同じだけ有効に 
なるでしよう。 

ライフタイム注釈が異なる具体的なライフタイムになる参照を渡すことで longest 関数を制限する 
方法を見ましょう。リスト 10-23 は、率直な例です。 

フ アイ ル名： src / main.rs 

# fn 10 ngest く ， a>(x: &'a str , y : &'a str) -> &'a str { 

# if x.len() > y.len() { 

# x 

# } else { 

# y 

# } 

# } 

# 

fn main() { 

/ /長い文字列は長い 

let stringl = String: : from("long string is long") ; 

{ 

let string2 = String: : from( M xyz") ; 

let result =longest(stringl.as_str(), string2.as_str()); 

println! ("The longest string is {}" , result); 



リスト 10-23: 異なる具体的なライフタイムの String 値への参照で longest 関数を使用する 

この例において、 stringl は外側のスコープの終わりまで有効で、 string 2 は内側のスコープの終 
わりまで有効、そして result は内側のスコープの終わりまで有効な何かを参照しています。このコー 
ドを実行すると、借用チヱッカーがこのコードに賛成するのがわかるでしょう。要するに、コンパイ 
ルでき、 The longest string is long string is long と出力するのです。 

次に、 result の参照のライフタイムが 2 つの引数の小さい方のライフタイムになることを示す例 
を試しましょう。 result 変数の宣言を内側のスコープの外に移すものの、 result 変数への代入は 
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string 2 のスコープ内に残したままにします。それから result を使用する println !を内側のスコー 
プの外、内側のスコープが終わった後に移動します。リスト 10-24 のコードはコンパイルできません。 

フアイル名： src / main.rs 
fn mann () { 

let stringl = String : : from("long string is long ") ; 
let result ; 

{ 

let string 2 = String : : from ( n xyz ") ; 

result = longest ( stringl . as _ str (), string 2. as _ str ()); 

} 

println! ("The longest string is {}" , result ); 

} 


リスト 10-24： string 2 がスコープを抜けてから result を使用しようとする 


この コードのコ ンパイルを試みると、こんなエラーになります: 

error[E0597] : stnng2 does not live long enough 
--> src/main.rs:15:5 


14 

15 

16 
17 


result =longest(stringl.as_str(), string2.as_str()); 

- borrow occurs here 

} 

a 'string2' dropped here while still borrowed 
println!("The longest string is {}", result); 

} 

- borrowed value needs to live until here 


このエラーは、 result が println ! 文に対して有効になるために、 string 2 が外側のスコープの終 
わりまで有効である必要があることを示しています。関数引数と戻り値のライフタイムを同じライフ 
タイム引数 1 a で注釈したので、コンパイラはこのことを知っています。 

人間からしたら、このコードを見て stri ngl は stri ng 2 よりも長いことが確認でき、故に result は 
stringl への参照を含んでいます。まだ stringl はスコープを抜けていないので、それでも stri ngl 
への参照は println ! にとって有効でしょう。ですが、コンパイラはこの場合、参照が有効であると 
見なせません。 longest 関数から返ってくる参照のライフタイムは、渡した参照のうちの小さい方と 
同じだとコンパイラに指示しました。それ故に、借用チェッカーは、リスト 10-24 のコードを無効な 
参照がある可能性があるとして許可しないのです。 

試しに値や longest 関数に渡される参照のライフタイムや返される参照の使用法が異なる実験を 
もっと企ててみてください。自分の実験がコンパイル前に借用チヱッカーを通るかどうか仮説を立て 
てください；そして、正しいか確かめてください！ 
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10.4.6 ライフタイムの観点で思考する 

ライフタイム引数を指定する必要のある手段は、関数が行っていることによります。例えば、 
longest 関数の実装を最長の文字列スライスではなく、常に最初の引数を返すように変更したら、 y 
引数に対してライフタイムを指定する必要はなくなるでしょう。以下のコードはコンパイルできます: 

フ アイ ル名： src / main.rs 

fn 10 ngest く ， a>(x : &'a str , y : & str ) -> &'a str { 
x 

} 

この例では、弓 I 数 X と戻り値に対してライフタイム引数 ' a を指定しましたが、弓 I 数 y には指定して 
いません。 y のライフタイムは x や戻り値のライフタイムとは何の関係もないからです。 

関数から参照を返す際、戻り値型のライフタイム引数は、引数のうちどれかのライフタイム引数と 
一致する必要があります。返される参照が引数のどれかを参照していなければ、この関数内で生成さ 
れた値を参照しているに違いなく、これは、その値が関数の末端でスコープを抜けるので、ダングリ 
ング参照になるでしょう。コンパイルできないこの longest 関数の未遂の実装を考えてください： 

フ アイ ル名： src / main.rs 

fn 10 ngest く ， a>(x : & str , y : & str ) -> &'a str { 

//本当に長い文字列 

let result = String : : from("rea Lly long string "); 
result . as _ str () 

} 


ここでは、たとえ、 戻り値型に ライフタイム 引数 ’ a を 指定して いても、 戻り値の ライフタイムは、 
引数の ライフタイムと 全く関係がない ので、この 実装は コンパイルで きないでしょう。 こちらが、 得 
られるエラーメ ッ セージです： 


error[E0597] : result does not Live long enough 

--> src/main.rs:3:5 


3 

4 


result.as_str() 

aaaaaa does not live Long enough 

} 

- borrowed value only lives until here 


note : borrowed value must be valid for the lifetime 'a as denned on the 
function body at 1:1... 

( 注釈：借用された値は、関数本体 1 行目 1 文字目で定義されているようにライフタイム 4 
に対して有効でなければなりません） 

——> src/mann.rs :1:1 
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2 

3 

4 


/ fn longest <' a >( x : & str , y : & str ) -> &'a str { 

| let result = String : : from("really long string "); 

| result . as _ str () 


問題は、 result が 10 ngest 関数の末端でスコープを抜け、片付けられてしまうことです 0 また、関 
数から result を返そうともしています。ダングリング参照を変えるであろうライフタイム引数を指 
定する手段はなく、コンパイラは、ダングリング参照を生成させてくれません。今回の場合、最善の 
修正案は、呼び出し元の関数が値の片付けに責任を持てるよう、参照ではなく所有されたデータ型を 
返すことでしょう。 

究極的にライフタイム記法は、関数のいろんな引数と戻り値のライフタイムを接続することに関す 
るのです。一旦、繫がりができたら、メモリ安全な処理を許可するのに十分な情報がコンパイラには 
あり、ダングリングポインタを生成するであろう処理を不認可し、さもなくばメモリ安全性を侵害す 
るのです。 


10.4.7 構造体定義のライフタイム注釈 

ここまで、所有された型を保持する構造体だけを定義してきました。構造体に参照を保持させるこ 
ともできますが、その場合、構造体定義の全参照にライフタイム注釈を付け加える必要があるでしょ 
う。リスト 10-25 には、文字列スライスを保持する ImportantExcerpt (重要な一節）という構造体が 
あります。 


フアイル名： src / mam.rs 


struct lmportantExcerpt<'a> { 
part: &'a str, 

} 

fn main() { 

// 僕をイシュマエルとお呼び。何年か前 •• • 

let novel = String: : from("Call me Ishmael. Some years ago 
let first_sentence = novel.split('.') 

.next() 

• expect ("Could not find a 丨•丨 n ) ; // ’ •丨が見つかりませんでした 

let i = ImportantExcerpt { part : first_sentence }; 

} 

リスト 10-25: 参照を含む構造体なので、定義にライフタイム注釈が必要 

この構造体には文字列スライスを保持する 1 つのフィールド、 part があり、これは参照です。ジェ 
ネリックなデータ型同様、構造体名の後、山カッコの中にジェネリックなライフタイム引数の名前を宣 
言するので、構造体定義の本体でライフタイム引数を使用できます。この注釈は、 ImportantExcerpt 
のインスタンスが、 part フィールドに保持している参照よりも長生きしないことを意味します。 
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ここの main 関数は、変数 novel に所有される String の最初の文への参照を保持する 
ImportantExcerpt インスタンスを生成しています。 novel のデータは、 ImportantExcerpt インスタ 
ンスが作られる前に存在しています。加えて 、 Important Excerpt がスコープを抜けるまで novel は 
スコープを抜けないので、 ImportantExcerpt インスタンスの参照は有効なのです。 

10.4.8 ライフタイム省略 

全参照にはライフタイムがあり、参照を使用する関数や構造体にはライフタイム引数を指定する必 
要があることを学びました。ですが、リスト 4-9 にとある関数があり、リスト 10-26 に再度示しまし 
たが、これは、ライフタイム注釈なしでコンパイルできました。 

ファイル名： src / lib.rs 

fn ti rst _ word ( s : & str ; -> &str { 
let bytes = s . as _ bytes (); 

for ( i ， & item ) in bytes . iter (). enumerate () { 
if item == b ' ' { 

return & s [0.. i ]; 

} 

} 

&s [..] 

} 


リスト 10-26: 弓 I 数と戻り値型が参照であるにも関わらず、ライフタイム注釈なしでコンパイルで 
きたリスト 4-9 で定義した関数 

この関数がライフタイム注釈なしでコンパイルできた理由は、歴史的なものです：昔のバージョン 
の Rust (1.0 以前）では、全参照に明示的なライフタイムが必要だったので、このコードはコンパイル 
できませんでした。その頃、関数シグニチヤはこのように記述されていたのです： 

fn first _ word <' a >( s : &'a str ) -> &'a str { 

多くの Rust コードを書いた後、 Rust チームは、 Rust プログラマが特定の場面では、何度も何度 
も同じライフタイム注釈を入力することを発見しました。これらの場面は予測可能で、いくつかの決 
定的なパターンに従っていました。開発者はこのパターンをコンパイラのコードに落とし込んだので、 
このような場面には借用チェッカーがライフタイムを推論できるようになり、明示的な注釈を必要と 
しなくなったのです。 

他の決定的なパターンが出現し、コンパイラに追加されることもあり得るので、この Rust の歴史 
は関係があります。将来的に、さらに少数のライフタイム注釈しか必要にならない可能性もあります。 

コンパイラの参照解析に落とし込まれたパターンは、ライフタイム省略規則と呼ばれます。これら 
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はプログラマが従う規則ではありません；コンパイラが考慮する一連の特定のケースであり、自分の 
コードがこのケースに当てはまれば、ライフタイムを明示的に書く必要はなくなります。 

省略規則は、完全な推論を提供しません。コンパイラが決定的に規則を適用できるけれども、参照 
が保持するライフタイムに関してそれでも曖昧性があるなら、コンパイラは、残りの参照がなるべき 
ライフタイムを推論しません。この場合、推論ではなく、コンパイラは、参照がお互いにどう関係す 
るかを指定するライフタイム注釈を追記することで、解決できるエラーを与えます。 

関数やメソッドの引数のライフタイムは、入カライフタイムと呼ばれ、戻り値のライフタイムは出 
カライフタイムと称されます。 

コンパイラは 3 つの規則を活用し、明示的な注釈がない時に、参照がどんなライフタイムになるか 
を計算します。最初の規則は入カライフタイムに適用され、 2 番目と 3 番目の規則は出カライフタイ 
ムに適用されます。コンパイラが 3 つの規則の最後まで到達し、それでもライフタイムを割り出せな 
い参照があったら、コンパイラはエラーで停止します。 

最初の規則は、参照である各弓 I 数は、独自のライフタイム引数を得るというものです。換言すれば、 
1 引数の関数は、 1 つのライフタイム引数を得るということです ： fn foo <' a >( x : &'a i 32) ; 2 つ引数 
のある関数は、 2 つの個別のライフタイム引数を得ます ： fn foo <' a , ' b >( x : &'a i 32, y : &'b i 32) 
； 以下同様。 

2 香目の規則は、1つだけ入カライフタイム引数があるなら、そのライフタイムが全ての出カライ 
フタイム引数に代入されるというものです ： fn foo <' a >( x : &'a i 32) -> &'a i 32。 

3 番目の規則は、複数の入カライフタイム弓 I 数があるけれども、メソッドなのでそのうちの一つが 
&self や &mut self だったら、 self のライフタイムが全出カライフタイム引数に代入されるというも 
のです。この 3 畨目の規則により、必要なシンボルの数が減るので、メソッドが遥かに読み書きしや 
すくなります。 

コンパイラになってみましょう。これらの規則を適用して、リスト 10-26 の first_word 関数のシ 
グニチヤの参照のライフタイムが何か計算します。シグニチヤは、参照に紐づけられるライフタイム 
がない状態から始まります： 

fn first _ word ( s : & str ) -> &str { 

そうして、コンパイラは最初の規則を適用し、各引数が独自のライフタイムを得ると指定します。 
それを通常通り 1 a と呼ぶので、シグニチヤはこうなります： 

fn first _ word <' a >( s : &'a str ) -> &str { 

1 つだけ入カライフタイムがあるので、2番目の規則を適用します。2畨目の規則は、1つの入力引 
数のライフタイムが、出力引数に代入されると指定するので、シグニチヤはこうなります： 

fn first _ word <' a >( s : &'a str ) -> &'a str { 


もうこの関数シグニチヤの全ての参照にライフタイムが付いたので、コンパイラは、プログラマに 
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この関数シグニチヤのライフタイムを注釈してもらう必要なく、解析を続行できます。 

別の例に目を向けましょう。今回は、リスト 10-21 で取り掛かったときにはライフタイム引数がな 
かった longest 関数です： 

fn longest ( x : & str , v : & str ) -> &str { 

最初の規則を適用しましょう：各弓 I 数が独自のライフタイムを得るのです。今回は、1つではなく 2 
つ引数があるので、ライフタイムも2つです： 

fn longest <' a , ' b >( x : &'a str , y : &'b str ) -> &str { 

2 つ以上入カライフタイムがあるので、 2 番目の規則は適用されないとわかります。また 3 番目の 
規則も適用されません。 10 ngest はメソッドではなく関数なので、どの引数も self ではないのです。 
3 つの規則全部を適用した後、まだ戻り値型のライフタイムが判明していません。このために、リスト 
10-21 でこのコードをコンパイルしようとしてエラーになったのです：コンパイラは、ライフタイム 
省略規則全てを適用したけれども、シグニチヤの参照全部のライフタイムを計算できなかったのです。 

3 畨目の規則は本当にメソッドシグニチヤでしか適用されないので、次にその文脈でライフタイム 
を観察し、 3 番目の規則が、メソッドシグニチヤであまり頻繁にライフタイムを注釈しなくても済む 
ことを意味する理由を確認します。 

10.4.9 メソッド定義におけるライフタイム注釈 

構造体にライフタイムのあるメソッドを実装する際、リスト 10-11 で示したジェネリックな型引数 
と同じ記法を使用します。ライフタイム引数を宣言し使用する場所は、構造体フィールドかメソッド 
引数と戻り値に関係するかによります。 

構造体のフィールド用のライフタイム名は、 impl キーワードの後に宣言する必要があり、それから 
構造体名の後に使用されます。そのようなライフタイムは構造体の型の一部になるからです。 

impl ブロック内のメソッドシグニチヤでは、参照は構造体のフィールドの参照のライフタイムに紐 
づくか、独立している可能性があります。カロえて、ライフタイム省略規則により、メソッドシグニチヤ 
でライフタイム注釈が必要なくなることがよくあります。リスト 10-25 で定義した ImportantExcerpt 
という構造体を使用して、何か例を眺めましょう。 

まず、唯一の引数が self への参照で戻り値が i 32 という何かへの参照ではない level というメ 
ソッドを使用します： 


# struct 丄 mportant ヒ xcerpt < 1 a > i 

# part : &'a str , 

# } 

# 

impl < ' a > ImportantExcerpt <' a > { 
fn level (& self ) -> i 32 { 
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} 

} 

impl 後のライフタイム引数宣言と型名の後に使用するのは必須ですが、最初の省略規則のため、 
self への参照のライフタイムを注釈する必要はありません。 

3番目のライフタイム省略規則が適用される例はこちらです： 

# struct ImportantExcerpt <' a > { 

# part : &'a str , 

# } 

# 

■ impl < ' a > ImportantExcerpt < ' a > { 

fn announce _ and _ return _ part (& self , announcement : & str ) -> &str { 

// お知らせします 

println! ("Attention please : {}" , announcement ); 
self •part 



2 つ入カライフタイムがあるので、コンパイラは最初のライフタイム省略規則を適用し、 & self と 
announcement に独自のライフタイムを与えます。それから、弓 I 数の1つが &self なので、戻り値型は 
&self のライフタイムを得て、全てのライフタイムが説明されました。 

10.4.10 静的ライフタイム 

議論する必要のある1種の特殊なライフタイムが、 ’static であり、これはプログラム全体の期間 
を示します。文字列リテラルは全て' static ライフタイムになり、次のように注釈できます： 

//静的ライフタイムを持ってるよ 

let s : &' static str = "I have a static liretime ." ; 

この文字列のテキストは、プログラムのバイナリに直接格納され、常に利用可能です。故に、全文 
字列リテラルのライフタイムは、 'static なのです。 

エラーメッセージで' static ライフタイムを使用する提言を目撃する可能性があります。ですが、 
参照に対してライフタイムとして 1 static を指定する前に、今ある参照が本当にプログラムの全期間 
生きるかどうか考えてください。可能であっても、参照がそれだけの期間生きてほしいかどうか考慮 
する可能性があります。ほとんどの場合、問題は、ダングリング参照を生成しようとしているか、利 
用可能なライフタイムの不一致が原因です。そのような場合、解決策はその問題を修正することであ 
り、 'static ライフタイムを指定することではありません。 
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10.5 ジェネリックな型引数、トレイト境界、ライフタイムを一度に 

ジェネリックな型引数、トレイト境界、ライフタイムを指定する記法を全て1関数でちょっと眺め 
ましょ5 ! 

use std :: fmt :: Di splay; 

fn 10 ngest_with_an_announcement く ， a ， T>(x: &'a str , v : &'a str, ann : T) -> &'a 
str 

where T : Display 

{ 

// アナウンス！ 

println! ("Announcement! {}" , ann); 
if x.len() > y.len() { 


} else { 

y 

} 

} 

これがリスト 10-22 からの 2 つの文字列のうち長い方を返す longest 関数ですが、ジェネリック 
な型 T の ann という追加の引数があり、これは where 節で指定されているように、 Display トレイト 
を実装するあらゆる型で埋めることができます。この追加の引数は、関数が文字列スライスの長さを 
比較する前に出力されるので、 Display トレイト境界が必要なのです。ライフタイムは1種のジェネ 
リックなので、ライフタイム引数 ' a とジェネリックな型引数 T が関数名の後、山カッコ内の同じリス 
卜に収まっています。 

10.6 まとめ 

いろんなことをこの章では講義しましたね！今やジヱネリックな型引数、トレイトとトレイト境 
界、そしてジヱネリックなライフタイム引数を知ったので、多くの異なる場面で動くコードを繰り返 
しなく書く準備ができました。ジェネリックな型引数により、コードを異なる型に適用させてくれま 
す。トレイトとトレイト境界は、型がジェネリックであっても、コードが必要とする振る舞いを持つ 
ことを保証します。ライフタイム注釈を活用して、この柔軟なコードにダングリング参照が存在し 
ないことを保証する方法を学びました。さらにこの解析は全てコンパイル時に起こり、実行時のパ 
フォーマンスには影響しません！ 

信じるかどうかは自由ですが、この章で議論した話題にはもっともっと学ぶベきことがあります: 
第17章ではトレイトオブジェクトを議論し、これはトレイトを使用する別の手段です。第19章で 
は、ライフタイム注釈が関わるもっと複雑な筋書きと何か高度な型システムの機能を講義します。で 
すが次は、 Rust でテストを書く方法を学ぶので、コードがあるべき通りに動いていることを確かめら 
れます。 
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自動テストを書く 


1972年のエッセイ「謙虚なプログラマ」でエドガー. W . ダイクストラは以下のように述べてい 
ます。「プログラムのテストは、バグの存在を示すには非常に効率的な手法であるが、バグの不在を示 
すには望み薄く不適切である」と。これは、できるだけテストを試みるべきではないということでは 
ありません。 

プログラムの正当性は、どこまで自分のコードが意図していることをしているかなのです。 Rust 
は、プログラムの正当性に重きを置いて設計されていますが、正当性は複雑で、単純に証明すること 
はありません。 Rust の型システムは、この重荷の多くの部分を肩代わりしてくれますが、型システム 
はあらゆる種類の不当性を捕捉してはくれません。ゆえに、 Rust では、言語内で自動化されたソフト 
ウェアテストを書くことをサポートしているのです。 

例として、渡された何かの数値に2を足す add _ two という関数を書くとしましょう。この関数のシ 
グニチャは、引数に整数を取り、結果として整数を返します。この関数を実装してコンパイルすると、 
コンパイラはこれまでに学んできた型チヱックと借用チヱックを全て行い、例えば、 String の値や無 
効な参照をこの関数に渡していないかなどを確かめるのです。ところが、コンパイラはプログラマが 
まさしく意図したことを関数が実行しているかどうかは確かめられません。つまり、そうですね、引 
数に10を足したり、50を引いたりするのではなく、引数に2を足していることです。そんな時に、 
テストは必要になるのです。 

例えば、 add _ two 関数に3を渡した時に、戻り値は5であることをアサーシヨンするようなテスト 
を書くことができます。コードに変更を加えた際にこれらのテストを走らせ、既存の正当な振る舞い 
が変わっていないことを確認できます。 

テストは、複雑なスキルです：いいテストの書き方をあらゆる方面から講義することは1章だけで 
はできないのですが、 Rust のテスト機構のメカニズムについて議論します。テストを書く際に利用可 
能になるアノテーシヨンとマクロについて、テストを実行するのに提供されているオプシヨンと標準 
の動作、さらにテストをユニットテストや統合テストに体系化する方法について語ります。 
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11.1 テストの記述法 

テストは、非テストコードが想定された方法で機能していることを実証する Rust の関数です。テ 
スト関数の本体は、典型的には以下の3つの動作を行います： 

1. 必要なデータや状態をセットアップする。 

2. テスト対象のコードを走らせる。 

3. 結果が想定通りかアサーシヨンする。 

Rust が、特にこれらの動作を行うテストを書くために用意している機能を見ていきましょう。これ 
には、 test 属性、いくつかのマクロ、 should _ panic 属性が含まれます。 

11.2 テスト関数の解剖 

最も単純には、 Rust におけるテストは test 属性で注釈された関数のことです。属性とは、 Rust 
コードの欠片に関するメタデータです；一例を挙げれば、構造体とともに第5章で使用した derive 属 
性です。関数をテスト関数に変えるには、 fn の前に# [ test ] を付け加えるのです 。 cargo test コマン 
ドでテストを実行したら、 コンパイ ラは test 属性で注釈された関数を走らせるテスト用バイナリを 
ビルドし、各テスト関数が通過したか失敗したかを報告します。 

第 7 章で、 Cargo で新規ライブラリプロジェクトを作成した時に、テスト関数が含まれるテストモ 
ジュールが自動で生成されたことを見かけました。このモジュールのおかげでテストを書き始めるこ 
とができるので、新しいプロジヱクトを立ち上げる度に、テスト関数の正確な構造と記法を調べる必 
要がなくなるわけです。必要なだけ追加のテスト関数とテストモジュールは追記することができます。 

実際にテストすることなしにテンプレートのテストが生成されるのを実験することでテストの動作 
法の一部の側面を探究しましょう。それから、自分で書いた何らかのコードを呼び出し、振る舞いが 
正しいかアサーシヨンする現実世界のテストを書きましょう。 
adder という新しいライブラリプロジェクトを生成しましょう： 


^ cargo new adder --lib 

Created library adder project 
$ cd adder 

adder •ライブラリの src/lib.rs ファイルの中身は、リスト 11_1 のような見た目のはずです。 


フアイル名： src/lib.rs 

# fn main () {} 

# [cfg(test)] 
mod tests { 

#[test] 

fn it _ works () { 
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assert _ eq ! (2 +2 ， 4) ; 

} 

} 

リスト 11-1: cargo new で自動生成されたテストモジュールと関数 

とりあえず、最初の2行は無視し、関数に集中してその動作法を見ましょう。 fn 行の# [ test ] 注 
釈に注目してください：この属性は、これがテスト関数であることを示唆しますので、テスト実行機 
はこの関数をテストとして扱うとわかるのです。さらに、 tests モジュール内には非テスト関数を入 
れ込み、一般的なシナリオをセットアップしたり、共通の処理を行う手助けをしたりもできるので、 
#[ test ] 属性でどの関数がテストかを示唆する必要があるのです。 

関数本体は、 asse 「 t _ eq ! マクロを使用して、2 + 2が4に等しいことをアサーシヨンしています。 
このアサーシヨンは、典型的なテストのフォーマット例をなしているわけです。走らせてこのテスト 
が通ることを確かめましょう。 

cargo test コマンドで プロジェクトにあるテストが全て実行されます。リスト 11-2 に示したよう 
にですね。 


$ cargo test 

Compiling adder v0.1.0 (file : ///proiects/adder) 

Finished dev [unoptimized + debuginfo] target(s) in 0.22 secs 
Running target/debug/deps/adder-ce99bcc2479f4607 


running 1 test 

test tests :: it_works ... ok 

test result : ok.1 passed; 0 failed; 0 ignored; 0 measured; 0 Tiltered out 
Doc-tests adder 
running 0 tests 

test result : ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 Tiltered out 

リスト 11-2: 自動生成されたテストを走らせた出力 

Cargo がテストをコンノ ^イルし、走らせました。 Compiling, Fi ni shed , Running の行の後に running 
1 test の行があります。次行が、生成されたテスト関数の it_works という名前とこのテストの実行 
結果、 ok を示しています。テスト実行の総合的なまとめが次に出現します 〇 test result:ok. という 
テキストは、全テストが通ったことを意味し、 1 passed; 0 failed と読める部分は、通過または失敗 
したテストの数を合計しているのです。 

無視すると指定したテストは何もなかったため、まとめは 0 ignored と示しています。また、実行 
するテストにフィルタをかけもしなかったので、まとめの最後に 0 filtered out と表示されていま 
す。テストを無視することとフィルタすることに関しては次の節、「テストの実行され方を制御する」 
で語ります。 
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0 measured という統計は、パフォーマンスを測定するベンチマークテスト用です。ベンチマークテ 
ストは、本書記述の時点では、ナイトリ版の Rust でのみ利用可能です。詳しくは、ベンチマークテ 
ストのドキュメンテーションを参照されたし。 

テスト出力の次の部分、つまり Doc-tests adder で始まる部分は、ドキュメンテーションテストの 
結果用のものです。まだドキュメンテーションテストは何もないものの、コンパイラは、 API ドキュ 
メントに現れたどんなコード例もコンパイルできます。この機能により、ドキュメントとコードを同 
期することができるわけです。ドキュメンテーションテストの書き方については、第14章の「テスト 
としてのドキュメンテーションコメント」節で議論しましょう。今は、 Doc - tests 出力は無視します。 

テストの名前を変更してどうテスト出力が変わるか確かめましょう。 it _ works 関数を違う名前、 
exploration などに変えてください。そう、以下のように： 

ファイル名： src/lib.rs 


# rn man n u {} 

^ [cfg(test)] 
mod tests { 

#[test] 

fn exploration () { 

assert _ eq ! (2 +2， 4); 



そして、 cargo test を再度走らせます。これで出力が it_works の代わりに exploration と表不し 
ています： 

running 1 test 

test tests :: exploration ... ok 

test result : ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 Tittered out 

別のテストを追加しますが、今回は失敗するテストにしましょう！テスト関数内の何かがパニック 
すると、テストは失敗します。各テストは、新規スレッドで実行され、メインスレッドが、テストス 
レッドが死んだと確認した時、テストは失敗と印づけられます。第9章でパニックを引き起こす最も 
単純な方法について語りました。要するに、 panic ! マクロを呼び出すことです。 src/lib.rs ファイル 
がリスト 11-3 のような見た目になるよう、新しいテスト another を入力してください。 

ファイル名： src/lib.rs 

# fn main() {} 

# [cfg(test)] 
mod tests { 

#[test] 

fn exploration () { 

assert_eq! (2 + 2, 4) ; 


} 
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#[test] 

fn another() { 

//このテストを失敗させる 
panic! ( n Make this test fail") ; 



リスト 11-3: panic ! マクロを呼び出したために失敗する2番目のテストを追加する 

cargo test で再度テストを走らせてください。出力はリスト 11-4 のようになるはずであり、 
exploration テストは通り、 another は失敗したと表示されます。 

running 2 tests 

test tests :: exploration ... ok 
test tests :: another ... FAILED 

failures : 

- tests :: another stdout - 

thread 'tests :: another' panicked at 'Make this test fail',src/lib.rs:10:8 
note : Run with 'RUST_BACKTRACE=1' for a backtrace. 


fan lures : 

tests :: another 

test result : FAILED.1 passed;1 failed; 0 ignored; 0 measured; 0 rn Ltered out 
error: test failed 


リスト 11-4: 一つの テストが通り、 一つが 失敗するとき の テスト結果 

ok の代わりに test test :: another の行は、 FAILED を表不しています。個々の結果とまとめの間 
に、2つ新たな区域ができました：最初の区域は、失敗したテスト各々の具体的な理由を表示していま 
す。今回の場合、 another は ， Make this test fail ，でパニックし たために失敗し、これは、 Src/lib.rS 
ファイルの10行で起きました。次の区域は失敗したテストの名前だけを列挙しています。これは、 
テストがたくさんあり、失敗したテストの詳細がたくさん表示されるときに有用になります。失敗し 
たテストの名前を使用してそのテストだけを実行し、より簡単にデバッグすることができます。テス 
卜の実行方法については、「テストの実行され方を制御する」節でもっと語りましょう。 

サマリー行が最後に出力されています：総合的に言うと、テスト結果は失敗でした。一つのテスト 
が通り、一つが失敗したわけです。 

異なる筋書きでのテスト結果がどんな風になるか見てきたので、テストを行う際に有用になる 
panic! 以外のマクロに目を向けましょう。 
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11.2.1 assert ! マクロで結果を確認する 

assert ! マクロは、標準ライブラリで提供されていますが、テスト内の何らかの条件が true と評価 
されることを確かめたいときに有効です。 assert ! マクロには、論理値に評価される引数を与えます。 
その値が true なら、 assert !は何もせず、テストは通ります。その値が false なら、 assert !マクロ 
は panic ! マクロを呼び出し、テストは失敗します。 assert ! マクロを使用することで、コードが意図 
した通りに機能していることを確認する助けになるわけです。 

第5章のリスト 5-15 で、 Rectangle 構造体と can_hold メソッドを使用しました。リスト 11-5 で 
もそれを繰り返しています。このコードを src / lib . rs ファイルに放り込み、 assert ! マクロでそれ用 
のテストを何か書いてみましょう。 

ファイル名： src/lib.rs 

# fn main () {} 

#[derive(Debug)] 
pub struct Rectangle { 
length : u 32 , 
width : u 32 , 

} 

impl Rectangle { 

pub fn can_hold (&self , other : & Rectangle ) -> bool { 

self .length > other.length && self .width > other.width 

} 

} 

リスト 11-5: 第 5 章から Rectangle 構造体とその can_hold メソッドを使用する 

can _ h 01 d メソッドは論理値を返すので、 assert !マクロの完璧なユースケースになるわけです。 
リスト 11-6 で、長さが8、幅が7の Rectangle インスタンスを生成し、これが長さ5、幅1の別 
の Rectangle インスタンスを保持できるとアサーシヨンすることで can _ hold を用いるテストを書き 
ます。 


フアイル名： src/lib.rs 

# fn main () {} 

# [cfg(test)] 
mod tests { 

use super : ; 


#[test] 

fn larger _ can _ hold _ smaller () { 

let larger = Rectangle { length : 8， width : 7 }; 
let smaller = Rectangle { length : 5， width :1}; 
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assert ! ( larger . can _ hold (& smaller )); 

} 

} 

リスト 11-6: より大きな四角形がより小さな四角形を確かに保持できるかを確認する can_hold 用 
のテスト 

tests モジュール内に新しい行を加えたことに注目してください： use super ::* です。 tests モ 
ジュールは、第 7 章の「プライバシー規則」節で講義した通常の公開ルールに従う普通のモジュール 
です。 tests モジュールは、内部モジュールなので、外部モジュール内のテスト配下にあるコードを 
内部モジュールのスコープに持っていく必要があります。ここでは glob を使用して、外部モジュー 
ルで定義したもの全てがこの tests モジュールでも使用可能になるようにしています 0 

テストは larger *_ can _ h 01 d_smaller と名付け、必要な Rectangle インスタンスを 2 つ生成してい 
ます。そして、 assert !マクロを呼び出し、 larger * • can _ h 01 d (& smaller ) の呼び出し結果を渡しまし 
た。この式は、 true を返すと考えられるので、テストは通るはずです。確かめましょう！ 

running 1 test 

test tests :: larger _ can _ hold_smaller ... ok 

test result : ok .1 passed ; 0 failed ; 0 ignored ; 0 measured ; 0 tiL tered out 

通ります！別のテストを追加しましょう。今回は、小さい四角形は、より大きな四角形を保持でき 
ないことをアサーシヨンします。 

ファイル名： src / lib.rs 

# fn main () {} 

#[cfg(test)] 

mod tests { 

use super ; 


#[test] 

fn larger _ can _ hold _ smaller () { 
// -- strip __ 

} 


#[test] 

fn sma Ller _ cannot _ hold _ larger () { 

let larger = Rectangle i Length : 8, width : 7 }; 
let smaller = Rectangle { length : 5, width :1}; 

assert ! (! smaller . can _ h 01 d (& larger )); 

} 

} 


今回の場合、 can _ hold 関数の正しい結果は false なので、その結果を assert !マクロに渡す前に 
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反車云させる必要があります。結果として、 can _ h 01 d が false を返せば、テストは通ります。 
running 2 tests 

test tests :: smaller _ cannot _ hold_larger ... ok 
test tests :: larger _ can _ hold_smaller ... ok 

test result : ok . 2 passed ; 0 failed ; 0 ignored ; 0 measured ; 0 Tittered out 

通るテストが 2 つ！さて、コードにバグを導入したらテスト結果がどうなるか確認してみましょう。 
長さを比較する大なり記号を小なり記号で置き換えて can _ h 0 ld メソッドの実装を変更しましょう： 

# fn main () {} 

# # [derive(Debug)] 

# pub struct Rectangle { 

# length : u 32, 

# width : u 32 , 

# } 

// --snip 
impl Rectangle { 

pub fn can_hold (&self , other : & Rectangle ) -> bool { 

self. Length < other.length && self .width > other.width 



テストを実行すると、以下のような出力をします： 
running 2 tests 

test tests :: smaller _ cannot _ hoid_larger ... ok 
test tests :: larger _ can _ hold_smaller ... FAILED 

failures : 

- tests :: larger _ can _ hold_smaller stdout - 

thread ' tests :: larger _ can _ hold _ smaller ' panicked at 'assertion failed : 
larger . can _ hold (& smaller )', src / lib . rs :22:8 

(ス レッ ド ， tests : : larger _ can _ h 01 d_smaller は src / lib . rs :22:8 の ， assertion failed 
: larger . can _ hold (& smaller )' 

でパニックしました） 

note : Run with ' RUST _ BACKTRACE =1' for a backtrace . 
failures : 

tests : : larger _ can _ hold_smaller 

test result : FAILED .1 passed ;1 failed ; 0 ignored ; 0 measured ; 0 filtered out 

テストによりバグが捕捉されました！ larger * • length が8 、 smaller • length が5なので、 can _ h 01 d 
内の長さの比較が今は false を返すようになったのです： 8は5より小さくないですからね。 
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11.2 .2 assert_eq !と assert _ ne ! マクロで等値性をテストする 

機能をテストする一般的な方法は、テスト下にあるコードの結果をコードが返すと期待される値と 
比較して、等しいと確かめることです。これを assert マクロを使用して==演算子を使用した式を渡 
すことで行うこともできます。しかしながら、これはありふれたテストなので、標準ライブラリには 
1 組のマクロ （ assert_eq !と assert_ne! ) が提供され、このテストをより便利に行うことができま 
す。これらのマクロはそれぞれ、二つの引数を等値性と非等値性のために比較します。また、アサー 
シヨンが失敗したら二つの値の出力もし、テストが失敗した原因を確認しやすくなります。一方で 
assert! マクロは、==式の値が false 値になったことしか示唆せず、 false 値に導いた値は出力しま 
せん。 

リスト 11-7 において、引数に 2 を加えて結果を返す add_two という名前の関数を書いています。 
そして、 assert_eq ! マクロで この関数をテストしています。 

ファイル名： src / lib.rs 
# fn main() {} 

pub fn add_two(a : i 32) -> i 32 { 
a + 2 

} 


# [cfg(test)] 
mod tests { 

use super : 


#[test] 

fn it _ adds _ two () { 

assert _ eq ! (4， add _ two (2)); 

} 

} 

リスト 11-7: assert_eq ! マクロで add_two 関数をテストする 
テストが通ることを確認しましょう！ 
running 1 test 

test tests : : it _ adds_two ... ok 

test result : ok .1 passed ; 0 failed ; 0 ignored ; 0 measured ; 0 filtered out 

assert _ eq ! マクロに与えた第 1 引数の 4 は、 add _ two ⑵の呼び出し結果と等しいです。このテス 
卜の行は test tests : : i t _ adds_two • ok であり、 ok というテキストはテストが通ったことを不し 
ています！ 

コードにバグを仕込んで、 assert _ eq ! を使ったテストが失敗した時にどんな見た目になるのか確認 



第 11 章自動テストを書く 


227 


してみましょう。 add_tw 。関数の実装を代わりに 3 を足すように変えてください： 

# fn main() {} 

pub fn add_two(a: i32) -> i32 { 
a + 3 

} 

テストを再度実行します： 
running 1 test 

test tests::it_adds_two ... FAILED 
fan lures : 

- tests: : it_adds_two stdout - 

thread 'tests :: it_adds_two' panicked at 'assertion failed : '(left == 
right)' 

left : ' 4 、 ， 

right: '5'', src/lib.rs:11:8 
note : Run with 'RUST_BACKTRACE=1' for a backtrace. 


failures : 

tests :: it _ adds_two 

test result : FAILED . 0 passed ;1 failed ; 0 ignored ; 0 measured ; 0 filtered out 

テストがバグを捕捉しました！ " it _ adds _ two のテストは失敗し 、 assertion failed: 、 （left == 
right )' というメッセージを表示し、 left は 4 で、 right は5だったと示しています。このメッセージ 
は有用で、デバッグを開始する助けになります： assert _ eq ! の left 引数は4だったが、 add _ two (2) 
がある right 引数は5だったことを意味しています。 

二つの値が等しいとアサ ーシ ヨンを行う関数の引数は、 expected と actual と呼ばれ、引数を指定 
する順序が問題になる言語やテストフレームワークもあることに注意してください。ですが Rust で 
は、 left と right と呼ばれ、期待する値とテスト下のコードが生成する値を指定する順序は、問題に 
なりません 0 assert_eq!(add_two(2), 4) と今回のテストのアサ ーシ ヨンを書くこともでき、そうす 
ると失敗メッセージは、 assertion failed : 、 （left == right )、 となり、 left が 5 で right が 4 と 
表示されるわけです。 

a SS er * t _ ne ! マクロは、与えた2つの値が等しくなければ通り、等しければ失敗します。このマク 
口は、値が何になるだろうか確信が持てないけれども、コードが意図した通りに動いていれば、確実 
にこの値にはならないだろうとわかっているような場合に最も有用になります。例えば、入力を何ら 
かの手段で変えることが保障されているけれども、入力が変更される方法がテストを実行する曜日に 
依存する関数をテストしているなら、アサーシヨンすべき最善の事柄は、関数の出力が入力と等しく 
ないことかもしれません。 

表面下では、 asser * t _ eq ! と assert _ ne !マクロはそれぞれ、==と！=演算子を使用しています。ア 
サーシヨンが 失敗すると、これらのマクロは引数をデバッグ フォー マットを使用して出力するので、 
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比較対象の値は PartialEq と Debug トレイトを実装していなければなりません。組み込み型の全部 
と、標準ライブラリの型はほぼ全てこれらのトレイトを実装しています。自分で定義した構造体と 
enum については 、 PartialEq を実装して、その型の値が等しいか等しくないかアサ ーシヨン する必 
要があるでしょう。 Debug を実装して、アサ ーシヨンが 失敗した時に値を出力する必要もあるでしょ 
う。第 5 章のリスト 5-12 で触れたように、どちらのトレイトも継承可能トレイトなので、これは通 
常、構造体や enum 定義に# [deri ve (Parti alEq ， Debug) ] という注釈を追加するくらい単純になり 
ます。これらや他の継承可能トレイトに関する詳細に ついては、 付録 C をご覧ください。 

11.2.3 カスタムの失敗メッセージを追加する 

さらに、 assert! 、 assert_eq! 、 assert_ne !の追加引数として、失敗メッセージと共にカスタム 
のメッセージが表示されるよう、追加することもできます。 assert! の 1 つの必須引数、あるいは 
assert_eq! と assert_ne !の 2 つの必須引数の後に指定された引数はどれも format ! マクロに 明け 
渡されるので、 （ format! マクロに ついては第 8 章の「+演算子または、 format ! マクロで 連結する」 
節で議論しました)、 {} プレースホルダーを 含む フォーマッ ト文字列とこの プレースホルダーに 置き 
換えられる値を渡すことができます。カスタムメッセージは、アサーシヨンがどんな意味を持つかド 
キュメント化するのに役に立ちます；テストが失敗した時、問題が何なのかコードと共により良い考 
えを持てるでしょう。 

例として、人々に名前で挨拶をする関数があり、関数に渡した名前が出力に出現することをテスト 
したいとしましょう： 

ファイル名： src/lib.rs 
# fn main() {} 

pub fn greeting(name : &str) -> String { 

/ / こんにちは、さん！ 
format ! ("Hello {}!"， name) 

} 


#[cfg(test)] 
mod tests { 

use super: ; 

#[test] 

fn greeting_contains_name() { 

let result = greeti ng("Carol") ; 
assert! (result. contains("Carol")) ; 



この プログラムの 必要事項はまだ合意が得られておらず、挨拶の先頭の Hello というテキストは変 
わるだろうということは極めて確かです。要件が変わった時にテストを更新しなくてもよいようにし 
たいと決定したので、 greeting 関数から返る値と正確な等値性を確認するのではなく、出力が入力引 
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数のテキストを含むことをアサーシヨンするだけにします。 

greeting が name を含まないように変更してこのコードにバグを仕込み、このテストの失敗がどん 
な見た目になるのか確かめましょう： 

# fn main () {} 

pub rn greeting ( name : & str ) -> String { 

Stri ng : : f rom (" Hello ! ") 

} 

このテストを実行すると、以下のように出力されます： 
running 1 test 

test tests :: greeting _ conta ] ns_name ... FAILED 
failures : 

- tests : : greeting _ contains_name stdout - 

thread ' tests :: greeting _ contains _ name ' panicked at 'assertion failed : 
result . contains (" Carol ")', src / lib . rs :12:8 
note : Run with ' RUST _ BACKTRACE =1' for a backtrace . 


failures : 

tests :: greeting _ contains_name 

この結果は、アサーシヨンが失敗し、どの行にアサーシヨンがあるかを示しているだけです。より 
有用な失敗メッセージは今回の場合、 greeting 関数から得た値を出力することでしょう 。 greeting 
関数から得た実際の値で埋められるプレースホルダーを含むフォーマット文字列からなるカスタムの 
失敗メッセージを与え、テスト関数を変更しましょう： 


# [test] 

fn greeting _ contains _ name () { 

let result = greeti ng (" CaroL ") ; 
assert ! ( 

result . contains (" Carol ") , 

// 挨拶は名前を含んでいません。値は' {} 'でした 

"Greeting did not contain name , value was , result 

)； 

} 

これでテストを実行したら、より有益なエラーメッセージが得られるでしょう： 

- tests :: greet ] ng _ conta ] ns_name stdout - 

thread ' tests :: greeting _ contains _ name ' panicked at 'Greeting did not 
contain name , value was ' Hello !' 1 ， src / lib . rs :12:8 
note : Run with ' RUST _ BACKTRACE =1' for a backtrace . 


実際に得られた値がテスト出力に見られ、起こると想定していたものではなく、起こったものをデ 
バッグするのに役に立ちます。 
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11.2 .4 should_panic でパニックを確認する 

期待する正しい値をコードが返すことを確認することに加えて、想定通りにコードがエラー状態を 
扱っていることを確認するのも重要です。例えば、第9章のリスト 9-9 で生成した Guess 型を考え 
てください。 Guess を使用する他のコードは、 Guess のインスタンスは 1 から 100 の範囲の値しか含 
まないという保証に依存しています。その範囲外の値で Guess インスタンスを生成しようとするとパ 
ニックすることを確認するテストを書くことができます。 

これは、テスト関数に should_panic という別の属性を追加することで達成できます。この属性は、 
関数内のコードがパニックしたら、テストを通過させます。つまり、関数内のコードがパニックしな 
かったら、テストは失敗するわけです。 

リスト 11-8 は、予想した時に Guess: :ne W のエラー条件が発生していることを確認するテストを示 
しています。 

ファイル名： src / lib.rs 

# fn main() {} 
pub struct Guess { 

value : u32, 

} 

impl Guess { 

pub fn new(value : u32) -> Guess { 
if value < 1 || value > 100 { 

// 予想値は 1 から 100 の間でなければなりません 

pam c ! ("Guess va Lue must be between 1 and 100 , got , value); 

} 

Guess { 
value 

} 

} 

} 

# [cfg(test)] 
mod tests { 

use super*: ; 

#[ test ] 

#[should_panic] 
fn greater_than_100() { 

Guess :: new(200); 

} 

} 


リスト 11-8: 状況が panic ! を引き起こすとテストする 
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#[ test ] 属性の後、適用するテスト関数の前に# [ should _ pam _ c ] 属性を配置しています。このテス 
卜が通るときの結果を見ましょう： 

running 1 test 

test tests : : greater _ than _100 ... ok 

test result : ok .1 passed ; 0 failed ; 0 ignored ; 0 measured ; 0 filtered out 

よさそうですね！では、値が 100 より大きいときに new 関数がパニックするという条件を除去す 
ることでコードにバグを導入しましょう： 

# fn main () {} 

# pub struct Guess i 

# value : u 32 , 

# } 

# 

// --snip 
impl Guess { 

pub fn new ( value : u 32) -> Guess { 
if value < 1{ 

panic! ( n Guess value must be between 1 and 100 , got , value ); 

} 

Guess { 
value 

} 

} 

} 

リスト 11-8 のテストを実行すると、失敗するでしょう： 
running 1 test 

test tests : : greater _ than _100 ... FAILED 
failures : 
failures : 

tests :: greater _ than _100 

test result : FAILED . 0 passed ;1 failed ; 0 ignored ; 0 measured ; 0 filtered out 

この場合、それほど役に立つメッセージは得られませんが、テスト関数に目を向ければ、# [ 
should _ panic ] で注釈されていることがわかります。得られた失敗は、テスト関数のコードがパニッ 
クを引き起こさなかったことを意味するのです。 

should_panic を使用するテストは不正確なこともあります。なぜなら、コードが何らかのパニック 
を起こしたことしか示さないからです。 should_panic のテストは、起きると想定していたもの以外 
の理由でテストがパニックしても通ってしまうのです。 should_panic のテストの正確を期すために、 
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should_panic 属性の省略可能な expected 引数を追加できます。このテストの拘束具が、失敗メッ 
セージに与えられたテキストが含まれていることを確かめてくれるでしょう。例えば、リスト 11-9 の 
Guess の変更されたコードを考えてください。ここでは、 new 関数は、値の大小によって異なるメッ 
セージでパニックします。 

ファイル名： src / lib.rs 

# fn mai . n () {} 

# pub struct Guess i 

# value : u 32 , 

# } 

# 

// -- snip -- 
impl Guess { 

pub fn new ( value : u 32) -> Guess { 
if value < 1{ 

// 予想値は、 1 以上でなければなりませんが、 {} でした 

panic ! ("Guess va Lue must be greater than or equal to 1 ， got {}•’’， 
value ); 

} else if value > 100 { 

// 予想値は 100 以下でなければなりませんが、 {} でした 
pam c ! ("Guess va Lue must be less than or equal to 100 , got , 
value ); 

} 

Guess { 
value 

} 

} 

} 


#[cfg(test)] 
mod tests { 

use super : 


#[test] 

// 予想値は 100 以下でなければなりません 

#isnould_pomc{expected = "Guess value must be less tnan or equal to 100")] 
fn greater _ than _100() { 

Guess :: new (200); 

} 

} 

リスト 11-9: 状況が特定のパニックメッセージで panic ! を引き起こすことをテストする 

should_panic 属性の expected 引数に置いた値が Guess : : new 関数がパニックしたメッセージの 
一部になっているので、このテストは通ります。予想されるパニックメッセージ全体を指定するこ 
ともでき、今回の場合、 Guess value must be less than or equal to 100 , got 200. となります 0 
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should _ panic の予想される引数に指定すると決めたものは、パニックメッセージの固有性や活動性、 
テストの正確性によります。今回の場合、パニックメッセージの一部でも、テスト関数内のコードが、 
else if value >100ケ^ースを実行していると確認するのに事足りるのです。 

expected メッセージありの should_pani c テストが失敗すると何が起きるのが確かめるために、 
if value <1と else if value > 100ブロックの本体を入れ替えることで再度コードにバグを仕込 
みましょう： 

if value < 1 { 

panic ! ("Guess value must be less than or equal to 100 ， got ij - ." , value ); 

} else if value > 100 { 

panic! ("Guess value must be greater than or equal to 1 ,got , value ); 

} 

should _ panic テストを実行すると、今回は失敗するでしょう： 
running 1 test 

test tests : : greater _ than _100 ... FAILED 
failures : 

- tests : : greater _ than _100 stdout - 

thread ' tests :: greater _ than _100' panicked at 'Guess value must be 
greater than or equal to 1 ， got 200.', src / lib . rs :11:12 
note : Run with ' RUST _ BACKTRACE =1' for a backtrace . 

note : Panic did not include expected string 'Guess value must be less than or 
equal to 100 ' 

(注釈：パニックには 1 Guess value must be less than or equal to 100 ’という予想され 
る文字列が含まれませんでした） 

failures : 

tests :: greater _ than _100 

test result : FAILED . 0 passed ;1 Tailed ; 0 ignored ; 0 measured ; 0 filtered out 

この失敗メッセージは、このテストが確かにまさしく予想通りパニックしたことを示唆しています 
が、ノ《ニックメッセージは、予想される文字列の 1 Guess value must be less than or equal to 100 ' 
を含んでいませんでした。実際に得られたパニックメッセージは今回の場合 、 Guess value must be 
greater than or equal to 1 ,got 200 でした。そうしてバグの所在地を割り出し始めることがで 
きるわけです！ 

今やテスト記法を複数知ったので、テストを走らせる際に起きていることに目を向け 、 cargo test 
で使用できるいろんなオプションを探究しましょう。 
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11.3 テストの実行され方を制御する 

cargo run がコードをコンパイルし、出来上がったバイナリを走らせるのと全く同様に、 cargo test 
はコードをテストモードでコンパイルし、出来上がったテストバイナリを実行します。コマンドライ 
ンオプションを指定して cargo test の規定動作を変更することができます。例えば、 cargo test で 
生成されるバイナリの規定動作は、テストを全て並行に実行し、テスト実行中に生成された出力を 
キャブチャして出力が表示されるのを防ぎ、テスト結果に関係する出力を読みやすくすることです。 

コマンド ラインオプションの中には cargo test にかかるものや、出来上がったテストバイナリに 
かかるものがあります。この 2 種の引数を区別するために、 cargo test にかかる引数を--という区 
分記号の後に列挙し、それからテストバイナリにかかる引数を列挙します。 cargo test --help を走 
らせると、 cargo test で使用できるオプションが表示され、 cargo test -- --help を走らせると、 
-という区分記号の後に使えるオプションが表示されます。 

11.3.1 テストを並行または連続して実行する 

複数のテストを実行するとき、標準では、スレッドを使用して並行に走ります。これはつまり、テ 
ストが早く実行し終わり、コードが機能しているいかんにかかわらず、反応をより早く得られること 
を意味します。テストは同時に実行されているので、テストが相互や共有された環境を含む他の共通 
の状態に依存してないことを確かめてください。現在の作業対象ディレクトリや環境変数などですね。 

例えば、各テストがディスクに test _ output . txt というファイルを作成し、何らかのデータを書き 
込むコードを走らせるとしてください。そして、各テストはそのファイルのデータを読み取り、ファ 
イルが特定の値を含んでいるとアサーションし、その値は各テストで異なります。テストが同時に走 
るので、あるテストが、他のテストが書き込んだり読み込んだりする間隙にファイルを上書きするか 
もしれません。それから2番目のテストが失敗します。コードが不正だからではなく、並行に実行さ 
れている間にテストがお互いに邪魔をしてしまったせいです。各テストが異なるファイルに書き込む 
ことを確かめるのが一つの解決策です；別の解決策では、一度に一つのテストを実行します。 

並行にテストを実行したくなかったり、使用されるスレッド数をよりきめ細かく制御したい場合、 
-test-threads フラグと使用したいスレッド数をテストバイナリに送ることができます。以下の例 
に目を向けてください： 

$ cargo test -- --test-threads=l 

テストスレッドの数を1にセットし、並行性を使用しないようにプログラムに指示しています。1 
スレッドのみを使用してテストを実行すると、並行に実行するより時間がかかりますが、状態を共有 
していても、お互いに邪魔をすることはありません。 
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11.3.2 関数の出力を表示する 

標準では、テストが通ると、 Rust のテストライブラリは標準出力に出力されたものを全てキャブ 
チャします。例えば、テストで println ! を呼び出してテストが通ると、 println ! の出力は、端末に 
表示されません；テストが通ったことを示す行しか見られないでしょう。テストが失敗すれば、残り 
の失敗メッセージと共に、標準出力に出力されたものが全て見えるでしょう。 

例として、リスト 11-10 は引数の値を出力し、10を返す馬鹿げた関数と通過するテスト1つ、失 
敗するテスト1つです。 

ファイル名： src / lib.rs 

fn pnnts _ and _ returns _10( a : i 32) -> i 32 i 
//{} という値を得た 
println! ("I got the value {}" , a ); 

10 

} 


# [cfg(test)] 
mod tests { 

use super : ; 

#[test] 

fn this _ test _ will _ pass () { 

let value = prints _ and _ returns _10(4); 
assert _ eq ! (10 ， value ); 

} 

#[test] 

fn this _ test _ will _ fail (){ 

let value = prints _ and _ returns _10(8); 
assert _ eq ! (5, value ); 



リスト 11-10: println ! を呼び出す関数用のテスト 

これらのテストを cargo test で実行すると、以下のような出力を目の当たりにするでしょう： 
running 2 tests 

test tests : : this _ test _ wiLl_pass ... ok 
test tests : : this _ test _ will_fail ... FAILED 

failures : 

- tests : : this _ test _ will_fail stdout - 

I got the value 8 

thread ' tests :: this _ test _ will _ fai 1 'panicked at 'assertion failed : '(left == 
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right)' 
left : 、 5 、， 

right: '10'' , src/lib.rs :19:8 
note : Run with 'RUST_BACKTRACE=1' for a backtrace. 

failures: 

tests :: this_test_will_fai1 

test result : FAILED.1 passed;1 failed; 0 ignored; 0 measured; 0 filtered out 

この出力のどこにも I got the value 4 と表示されていないことに注意してください。これは、テ 
ストに合格した場合に出力されるものです。その出力はキャブチャされてしまいました。失敗したテ 
ストのからの出力 I got the value 8 がテストサマリー出力のセクションに表示され、テストが失敗 
した原因も示されます。 

通過するテストについても出力される値が見たかったら、出カキャブチャ機能を -- nocapture フラ 
グで無効化することができます： 

^ cargo test -- --nocapture 

リスト 11-10 のテストを --nocapture フラグと共に再度実行したら、以下のような出力を目の当た 
りにします： 

running 2 tests 
I got the value 4 
I got the value 8 

test tests::this_test_will_pass ... ok 

thread 'tests :: this_test_will_fai1'panicked at 'assertion failed : '(left == 
right)' 
left: '5 、， 

right: '10'', src/lib.rs:19 : 8 
note : Run with 'RUST_BACKTRACE=1' for a backtrace. 
test tests::this_test_will_fail...FAILED 


failures : 
failures : 

tests :: this _ test _ will _ fai 1 

test result : FAILED .1 passed ;1 failed ; 0 ignored ; 0 measured ; 0 filtered out 

テスト用の出力とテスト結果の出力がまぜこぜになっていることに注意してください；その理由 
は、前節で語ったようにテストが並行に実行されているからです。 - test - threads=l オプションと 
--nocapture フラグを使ってみて、その時、出力がどうなるか確かめてください！ 
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11.3.3 名前でテストの一部を実行する 

時々、全テストを実行すると時間がかかってしまうことがあります。特定の部分のコードしか対象 
にしていない場合、そのコードに関わるテストのみを走らせたいかもしれません。 cargo test に走ら 
せたいテストの名前を引数として渡すことで、実行するテストを選ぶことができます。 

テストの一部を走らせる方法を模擬するために、リスト 11-11 に示したように、 add_two 関数用に 
3つテストを作成し、走らせるテストを選択します。 

ファイル名： src / lib.rs 

pub fn add _ two ( a : i 32) -> i 32 { 
a + 2 

} 


# [cfg(test)] 
mod tests { 

use super : ; 

#[test] 

fn add _ two _ and _ two () { 

assert _ eq ! (4, add _ two (2)); 

} 


#[test] 

fn add _ three _ and _ two () { 

assert _ eq ! (5, add _ two (3)); 

} 


#[test] 

fn one _ hundred () { 

assert _ eq ! (102, add _ two (100) ); 

} 


リスト 11-11: 異なる名前の 3 つのテスト 


以前見かけたように、引数なしでテストを走らせたら、全テストが並行に走ります： 

running 3 tests 

test tests : : add _ two _ and_two ... ok 
test tests : : add _ three _ and_two ... ok 
test tests :: one_hundred ... ok 

test result : ok . 3 passed ; 0 failed ; 0 ignored ; 0 measured ; 0 filtered out 
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11.3 .3.1 単独のテストを走らせる 

あらゆるテスト関数の名前を cargo test に渡して、そのテストのみを実行することができます： 

$ cargo test one_hundred 

Finished dev [unoptimized + debuginfo 」 target ( s)in 0.0 secs 
Running target / debug / deps / adder -06 a 75 b 4 alf 2515 e 9 

running 1 test 

test tests :: one_hundred ... ok 

test result : ok .1 passed ; 0 failed ; 0 ignored ; 0 measured ; 2 riLtered out 

one_hundred という名前のテストだけが走りました；他の2つのテストはその名前に合致しなかっ 
たのです。まとめ行の最後に2 filtered out と表示することでテスト出力は、このコマンドが走ら 
せた以上のテストがあることを知らせてくれています。 

この方法では、複数のテストの名前を指定することはできません； cargo test に与えられた最初の 
値のみが使われるのです。ですが、複数のテストを走らせる方法もあります。 

11.3 .3.2 複数のテストを実行するようフィルターをかける 

テスト名の一部を指定でき、その値に合致するあらゆるテストが走ります。例えば、我々のテスト 
の2つが add という名前を含むので、 cargo test add を実行することで、その二つを走らせること 
ができます： 


$ cargo test add 

Finished dev [unoptimized + debuginfo 」 target ( s)in 0.0 secs 
Running target / debug / deps / adder -06 a 75 b 4 alf 251569 

running 2 tests 

test tests : : add _ two _ and_two ... ok 
test tests : : add _ three _ and_two ... ok 

test result : ok . 2 passed ; 0 failed ; 0 ignored ; 0 measured ;1 n Ltered out 

この コマンドは 名前に add を含むテストを全て実行し、 one_hundred という名前のテストを除外し 
ました。また、テストが出現するモジュールがテスト名の一部になっていて、モジュール名でフィル 
ターをかけることで、あるモジュール内のテスト全てを実行できることに注目してください。 

11.3.4 特に要望のない限りテストを無視する 

時として、いくつかの特定のテストが実行するのに非常に時間がかかることがあり、 cargo test の 
実行のほとんどで除外したくなるかもしれません。弓 I 数として確かに実行したいテストを全て列挙す 
るのではなく、ここに示したように代わりに時間のかかるテストを ignore 属性で除外すると注釈す 
ることができます。 
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ファイル名： src/lib.rs 

# [test] 

fn it _ works () { 

assert _ eq ! (2 + 2, 4); 

} 

#[test] 

#[ignore] 

fn expensive _ test () { 

// 実行に 1 時間かかるコード 
// code that takes an hour * to run 

} 

#[ test ] の後の除外したいテストに# [ ignore ] 行を追加しています。これで、テストを実行したら、 
it_works は実行されるものの、 expensive_test は実行されません： 

5 cargo test 

Compiung adder v 0.1.0 (n ie :/// projects / adder ) 

Finished dev [unoptimized + debuginfo ] target ( s ) in 0.24 secs 
Running target / debug / deps / adder - ce 99 bcc 2479 f 4607 

running 2 tests 

test expensive_test ... ignored 
test it_works ... ok 

test result : ok .1 passed ; 0 failed ;1 ignored ; 0 measured ; 0 filtered out 

expensive_test 関数は、 ignored と列挙されています。無視されるテストのみを実行したかった 
ら、 cargo test -- --ignored を使うことができます： 

^ cargo test ----ignored 

Finished dev [unoptimized + debuginfo ] target ⑻ in 0.0 secs 
Running target / debug / deps / adder - ce 99 bcc 2479 f 4607 

running 1 test 

test expensive_test ... ok 

test result : ok .1 passed ; 0 failed ; 0 ignored ; 0 measured ;1 filtered out 

どのテストを 走らせるか制御する ことで、 結果が早く出る ことを 確かめる ことができるのです。 
ignored テストの 結果を確認する ことが 道理に合い、結果を待つ だけの 時間が できたときに、 代わり 
に cargo test -- --ignored を走らせる ことができます。 

11.4 テストの体系化 


章の初めで触れたように、テストは複雑な鍛錬であり、人によって専門用語や体系化が異なります。 
Rust のコミュニテイでは、テストを2つの大きなカテゴリで捉えています：単体テストと結合テスト 
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です。単体テストは小規模でより集中していて、個別に1回に1モジュールをテストし、非公開の 
インターフェイスもテストすることがあります。結合テストは、完全にライブラリ外になり、他の外 
部コード同様に自分のコードを使用し、公開インターフヱイスのみ使用し、1テストにつき複数のモ 
ジュールを用いることもあります。 

どちらのテストを書くのも、ライブラリの一部が個別かつ共同でしてほしいことをしていることを 
確認するのに重要なのです。 

11.4.1 単体テスト 

単体テストの目的は、残りのコードから切り離して各単位のコードをテストし、コードが想定通り、 
動いたり動いていなかったりする箇所を迅速に特定することです。単体テストは、テスト対象となる 
コードと共に、 src ディレクトリの各ファイルに置きます。慣習は、各ファイルに tests という名前 
のモジュールを作り、テスト関数を含ませ、そのモジュールを cfg ( test ) で注釈することです。 


11.4 .1.1 テストモジユーノレと# [ cfg ( test )] 

tests モジュールの# [ cfg ( test ) ] という注釈は、コンパイラに cargo build を走らせた時ではな 
く、 cargo test を走らせた時にだけ、テストコードをコンパイルし走らせるよう指不します。これ 
により、ライブラリをビルドしたいだけの時にはコンパイルタイムを節約し、テストが含まれないの 
で、コンパイル後の成果物のサイズも節約します。結合テストは別のディレクトリに存在することに 
なるので、 #[ cfg ( test )] 注釈は必要ないとわかるでしょう。しかしながら、単体テストはコードと同 
じファイルに存在するので、 #[ cfg ( test )] を使用してコンパイル結果に含まれないよう指定するの 
です。 

この章の最初の節で新しい adder プロジェクトを生成した時に、 Cargo がこのコードも生成してく 
れたことを思い出してください： 

ファイル名： src / lib.rs 


# icfg(test)j 
mod tests { 

#[test] 

fn it _ works () { 

assert _ eq ! (2 + 2, 4); 



このコードが自動生成されたテストモジュールです。 cfg という属性は、 configuration を表して 
いて、コンパイラに続く要素が、ある特定の設定オプションを与えられたら、含まれるように指示し 
ます。今回の場合、設定オプションは、 test であり、言語によって提供されているテストをコンパイ 
ルし、走らせるためのものです。 cfg 属性を使用することで、 cargo test で積極的にテストを実行し 
た場合のみ、 Cargo がテストコードをコンパイルします。これには、このモジュールに含まれるかも 
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しれないヘルパー関数全ても含まれ、 #[test] で注釈された関数だけにはなりません。 

11.4.1.2 非公開関数をテストする 

テストコミュニティ内で非公開関数を直接テストするべきかについては議論があり、他の言語では 
非公開関数をテストするのは困難だったり、不可能だったりします。あなたがどちらのテストイデオ 
ロギーを支持しているかに関わらず、 Rust の公開性規則により、非公開関数をテストすることが確か 
に可能です。リスト 11-12 の非公開関数 interna し adder を含むコードを考えてください。 

ファイル名： src / lib.rs 

pub fn add_two(a : i32) -> i32 { 
internal_adder(a, 2) 

} 

fn internal_adder(a : i32 } b: -i32) -> i32 { 
a + b 

} 

# [cfg(test)] 
mod tests { 

use super: ; 

#[test] 

fn internal(){ 

assert_eq! (4, i nternal_adder(2, 2)); 

} 

} 

リスト 11-12: 非公開関数をテストする 

i nternal_adder 関数は pub とマ ー クされていないものの、テストも単なる Rust のコー ドであり、 
tests モジユールもただのモジユールでしかないので、テスト内で i nternal_adder を普通にインポー 
卜し呼び出すことができます。非公開関数はテストするべきではないとお考えなら、 Rust にはそれを 
強制するものは何もありません。 


11.4 .2 結合テスト 

Rust において、結合テストは完全にライブラリ外のものです。他のコードと全く同様にあなたのラ 
イブラリを使用するので、ライブラリの公開 API の一部である関数しか呼び出すことはできません。 
その目的は、ライブラリのいろんな部分が共同で正常に動作しているかをテストすることです。単体 
では正常に動くコードも、結合した状態だと問題を孕む可能性もあるので、結合したコードのテスト 
の範囲も同様に重要になるのです。結合テストを作成するには、まず tests ディレクトリが必要にな 
ります。 
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11.4 .2.1 tests ディレクトリ 

プロジェクトディレクトリのトツプ階層、 src の隣に tests ディレクトリを作成します。 Cargo は、 
このディレクトリに結合テストのファイルを探すことを把握しています。そして、このディレクトリ 
内にいくらでもテストファイルを作成することができ、 Cargo はそれぞれのファイルを個別のクレー 
卜としてコンパイルします。 

結合テストを作成しましよう。リスト 11 -12 のコードが src/lib.rs ファイルにあるまま、 tests 
ディレクトリを作成し、 tests/integration_test.rs という名前の新しいファイルを生成し、リスト 
11-13 のコードを入力してください。 

フアイル名： tests / integration _ test.rs 

extern crate adder; 


#[test] 

fn it_adds_two() { 

assert_eq! (4 ， adder :: add_two(2)); 

} 

リスト 11-13： adder クレートの関数の結合テスト 

コードの頂点に extern crate adder を追記しましたが、これは単体テストでは必要なかったもの 
です。理由は、 tests ディレクトリのテストはそれぞれ個別のクレートであるため、各々ライブラリ 
をインポートする必要があるためです。 

tests/integration_test.rs のどんなコードも# [ cfg ( test )] で注釈する必要はありません。 Cargo 
は tests ディレクトリを特別に扱い 、 cargo test を走らせた時にのみこのディレクトリのファイル 
をコンパイルするのです。さあ 、 cargo test を実行してください： 


$ cargo test 

Compiling adder v0.1.0 (file:///proiects/adder) 

Finished dev [unoptimized + debuginfo] target(s) in 0.31 secs 
Running target/debug/deps/adder-abcabcabc 

running 1 test 

test tests::internal ... ok 

test result : ok.1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out 

Running target/debug/deps/integration_test-ce99bcc2479f4607 

running 1 test 

test it_adds_two ... ok 

test result : ok.1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out 


Doc-tests adder 
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running 0 tests 

test result : ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 n Ltered out 

3 つの区域の出力が単体テスト、結合テスト、ドックテストを含んでいます。単体テスト用の最初 
の区域は、今まで見てきたものと同じです：各単体テストに 1 行（リスト 11-12 で追加した internal 
という名前のもの）と、単体テストのサマリー行です。 

糸吉合テストの区域は、 Running target/debug/deps/integration-test-ce99bcc2479f4607 といつ 
行で始まっています（最後のハッシュはあなたの出力とは違うでしょう）。次に、この結合テストの各 
テスト関数用の行があり、 Doc-tests adder 区域が始まる直前に、結合テストの結果用のサマリー行 
があります。 

単体テスト関数を追加すると、単体テスト区域のテスト結果の行が増えることに似て、作成した結 
合テストファイルにもっとテスト関数を追加すると、そのファイルの区域に行が増えることになりま 
す。結合テストファイルはそれぞれ独自の区域があるため、 tests ディレクトリにさらにファイルを 
追加すれば、結合テストの区域が増えることになるでしょう。 

それでも、テスト関数の名前を引数として cargo test に指定することで、特定の結合テスト関数を 
走らせることができます。特定の結合テストファイルにあるテストを全て走らせるには 、 cargo test 
に-- test 弓 I 数、その後にファイル名を続けて使用してください： 

$ cargo test --test integration_test 

Finished dev [unoptimized + debuginfo 」 target(s)in 0.0 secs 
Running target/debug/integration_test-952a27e 0126 bb565 

running 1 test 

test it_adds_two ... ok 

test result : ok.1 passed; 0 failed; 0 ignored; 0 measured; 0 riLtered out 

この コマン ドは、 tests/integration_test.rs ファイルにあるテストのみを実行します。 

11.4.2.2 結合テスト内のサブモジユール 

結合テストを追加するにつれて、 tests ディレクトリに2つ以上のファイルを作成して体系化し 
たくなるかもしれません；例えば、テスト対象となる機能でテスト関数をグループ化することができ 
ます。前述したように、 tests ディレクトリの各ファイルは、個別のクレートとしてコンパイルされ 
ます。 

各結合テストファイルをそれ自身のクレートとして扱うと、エンドユーザがあなたのクレートを使 
用するかのように個別のスコープを生成するのに役立ちます。ですが、これは tests ディレクトリの 
ファイルが、コードをモジュールとファイルに分ける方法に関して第 7 章で学んだように、 src の 
ファイルとは同じ振る舞いを共有しないことを意味します。 

tests ディレクトリのファイルの異なる振る舞いは、複数の結合テストファイルで役に立ちそうな 
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ヘルパー関数ができ、第7章の「モジュールを別のファイルに移動する」節の手順に従って共通モ 
ジュールに抽出しようとした時に最も気付きやすくなります。例えば、 tests / common . rs を作成 
し、そこに setup という名前の関数を配置したら、複数のテストファイルの複数のテスト関数から呼 
び出したい setup に何らかのコードを追加することができます： 


ファイル名： tests / common.rs 

pub rn setupu { 

// ここにライブラリテスト固有のコードが来る 

// setup code specific to your library's tests would go here 

} 

再度テストを実行すると、 common.rs ファイルは何もテスト関数を含んだり、 setup 関数をどこ 
かから呼んだりしてないのに、テスト出力に common.rs 用の区域が見えるでしょう。 

running 1 test 

test tests :: nnternal ... ok 

test result : ok.1 passed; 0 failed; 0 ignored; 0 measured; 0 Tiltered out 
Running target/debug/deps/common-b8b07b6flbe2db70 
running 0 tests 

test result : ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 Tiltered out 

Running target/debug/deps/integration_test-d993c68b431d39df 

running 1 test 

test it_adds_two ... ok 

test result : ok.1 passed; 0 failed; 0 ignored; 0 measured; 0 Tiltered out 
Doc-tests adder 
running 0 tests 

test result : ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 Tiltered out 

common が running 0 tests とテスト結果に表示されるのは、望んだ結果ではありません。ただ単 
に他の結合テストファイルと何らかのコードを共有したかっただけです。 

common がテスト出力に出現するのを防ぐには、 tests/common.rs を作成する代わりに、 
tests/common/mod.rs を作成します。第 7 章の「モジュールファイルシステムの規則」節におい 
て、 module_name/mod.rs という命名規則をサブモジュールのあるモジュールのファイルに使用 
しました。ここでは common にサブモジュールはありませんが、このように命名することでコンパイ 
ラに common モジュールを結合テストファイルとして扱わないように指示します。 setup 関数のコー 
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ドを tests / common / mod . rs に移動し、 tests / common . rs ファイルを削除すると、テスト出力 

に区域はもう表示されなくなります。 tests ディレクトリのサブディレクトリ内のファイルは個別ク 
レートとしてコンパイルされたり、テスト出力に区域が表示されることがないのです。 

tests / common / mod . rs を作成した後、それをどの結合テストファイルからもモジュールとし 
て使用することができます。こちらは、 tests / integration _ test . rs 内の it_adds_two テストから 
setup 関数を呼び出す例です： 

フアイル名： tests/integration_test.rs 

extern crate adder; 
mod common; 


#[test] 

fn it_adds_two() { 
common :: setup(); 

assert_eq! (4, adder :: add_two(2)); 

} 

mod common; という宣言は、リスト 7-4 で模擬したモジュール宣言と同じであることに注意してく 
ださい。それから、テスト関数内で common: :setup() 関数を呼び出すことができます 0 

11.4 .2.3 バイナリクレート用の結合テスト 

もしもプロジェクトが src / main . rs ファイルのみを含み、 src / lib . rs ファイルを持たないバ 
イナリクレートだったら、 tests ディレクトリに結合テストを作成し、 extern crate を使用して 
src / main . rs ファイルに定義された関数をインポートすることはできません。ライブラリクレート 
のみが、他のクレートが呼び出して使用できる関数を晒せるのです；バイナリクレートはそれ単体で 
実行することを意味しています。 

これは、バイナリを提供する Rust のプロジェクトに、 src / lib . rs ファイルに存在するロジックを 
呼び出す単純な src / main . rs ファイルがある一因になっています。この構造を使用して結合テスト 
は、 extern crate を使用して重要な機能を用いることでライブラリクレートをテストすることがで 
きます。この重要な機能が動作すれば、 src / main . rs ファイルの少量のコードも動作し、その少量の 
コードはテストする必要がないわけです。 

11.5 まとめ 

Rust のテスト機能は、変更を加えた後でさえ想定通りにコードが機能し続けることを保証して、 
コードが機能すべき方法を指定する手段を提供します。単体テストはライブラリの異なる部分を個別 
に用い、非公開の実装詳細をテストすることができます。結合テストは、ライブラリのいろんな部分 
が共同で正常に動作することを確認し、ライブラリの公開 API を使用して外部コードが使用するのと 
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同じ方法でコードをテストします。 Rust の型システムと所有権ルールにより防がれるバグの種類も 
あるものの、それでもテストは、コードが振る舞うと予想される方法に関するロジックのバグを減ら 
すのに重要なのです。 

この章と以前の章で学んだ知識を結集して、とあるプロジヱタトに取り掛かりましょう！ 
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12； 


入出カプロジェクト：コマンドラインプ 
ログラムを構築する 


この章は、ここまでに学んできた多くのスキルを思い出すきっかけであり、もういくつか標準ライ 
ブラリの機能も探究します。ファイルやコマンドラインの入出力と相互作用するコマンドラインツー 
ルを構築し、今やあなたの支配下にある Rust の概念の一部を練習していきます。 

Rust の速度、安全性、単バイナリ出力、クロスプラットフォームサポートにより、 コマンド ライ 
ンツールを作るのにふさわしい言語なので、このプロジェクトでは、独自の伝統的な コマンド ライン 
ツールの grep (globally search a regular expression and print : 正規表現をグローバルで検索 
し表示する）を作成していきます。最も単純な使用法では、 grep は指定したファイルから指定した文 
字列を検索します。そうするには、 grep は引数としてファイル名と文字列を受け取ります。それから 
ファイルを読み込んでそのファイル内で文字列引数を含む行を探し、検索した行を出力するのです。 

その過程で、多くのコマンドラインツールが使用している端末の機能を使用させる方法を示します。 
環境変数の値を読み取ってユーザがこのツールの振る舞いを設定できるようにします。また、標準出 
力 （ stdout) の代わりに、標準エラーに出力 （ stderr) するので、例えば、ユーザはエラーメッセージ 
は画面上で確認しつつ、成功した出力はファイルにリダイレクトできます。 

Rust コミュニティの あるメンバである アンドリュー . ガラント (Andrew Gallant ) が 既に全機能 
装備の非常に高速な grep、ripgr 印と呼ばれるものを作成しました。比較対象として、我々の grep 
はとても単純です が、 この章により、 ripgrep のような現実世界のプロ ジヱク トを理解するのに必要 
な背景知識の一部を身に付けられるでしょう。 

この grep プロジェクトは、ここまでに学んできた多くの概念を集結させます： 

• コードを体系化する（モジュール、第7章で学んだことを使用） 

• ベクタと文字列を使用する（コレクション、第8章） 

• ェラーを処理する（第9章） 

• 適切な箇所でトレイトとライフタイムを使用する（第10章） 
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• テストを記述する（第11章） 

さらに、クロージャ、イテレータ、トレイトオブジェクトなど、第 13 章、 17 章で詳しく講義する 
ものもちょっとだけ紹介します。 

12.1 コマンドライン引数を受け付ける 

いつものように 、 cargo new で新しいプロジェクトを作りましょう。プロジェクトを mi nigrep と 
名付けて、既に自分のシステムに存在するかもしれない grep ツールと区別しましょう。 

最初の仕事は、 minigrep を二つの引数を受け付けるようにすることです：ファイル名と検索する文 
字列ですね。つまり 、 cargo run で検索文字列と検索を行うファイルへのパスと共にプログラムを実 
行できるようになりたいということです。こんな感じにね： 

$ cargo run searchstnng example-Titename.txt 

今現在は 、 cargo new で生成されたプログラムは、与えた引数を処理できません。 Crates . io に存在 
する既存のライブラリには、コマンドライン引数を受け付けるプログラムを書く手助けをしてくれる 
ものもありますが、ちょうどこの概念を学んでいる最中なので、この能力を自分で実装しましょう。 

12.1.1 引数の値を読み取る 

mim _ grep が渡したコマンドライン引数の値を読み取れるようにするために、 Rust の標準ライブラ 
リで提供されている関数が必要になり、それは、 std : : env : : args です。この関数は、 minigrep に与 
えられたコマンドライン引数のイテレータを返します。イテ レー タについてはまだ議論していません 
(完全には第 13 章で講義します）が、とりあえずイテ レー タに関しては、 2 つの詳細のみ知っていれ 
ばいいです：イテ レー タは一連の値を生成することと、イテ レー タに対して collect 関数を呼び出し、 
イテ レー タが生成する要素全部を含むベクタなどの コレ クシヨンに変えられることです。 

リスト 12-1 の コー ドを使用して minigrep プログラムに渡されたあらゆる コマンド ライン引数を 
読み取れるようにし、それからその値をベクタとして集結させてください。 

フアイル名： src / main.rs 

use std :: env; 

fn mann() { 

let args : Vec < String > = env : : args (). collect (); 
println ! ("{:?}" , args ); 

} 

リスト 12-1: コマンドライン引数をベクタに集結させ、出力する 

まず、 std : : env モジュールを use 文でスコープに導入したので、 args 関数が使用できます。 std :: 
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env : : args 関数は、2 レベル モジュールがネストされていることに気付いてください。第7章で議論 
したように、希望の関数が2モジュール以上ネストされている場合、関数ではなく親モジュールをス 
コープに導入するのが因習的です。そうすることで、 std :: env から別の関数も容易に使用することが 
できます。また 、 use std : : env : : args を追記し、関数を args とするだけで呼び出すのに比べて曖昧 
でもありません。というのも、 args は現在のモジュールに定義されている関数と容易に見間違えられ 
るかもしれないからです。 

12.1.2 args 関数と不正なユニコード 


引数のどれかが不正なユニコードを含んでいたら、 std : : env : :args はパニックすることに注 
意してください。プログラムが不正なユニコードを含む引数を受け付ける必要があるなら、代 
わりに std : : env : : args_os を使用してください。この関数は、 String 値ではなく、 OsString 
値を生成するイテレータを返します。ここでは、簡潔性のために std : : env : :args を使うこと 
を選択しました。なぜなら、 OsString 値はプラットフォームごとに異なり、 String 値に比べ 
て取り扱いが煩雑だからです。 

main の最初の行で env : :args を呼び出し、そして即座に collect を使用して、イテレータをイテ 
レータが生成する値全てを含むベクタに変換しています。 collect 関数を使用して多くの種類のコ 
レクションを生成することができるので、 args の型を明示的に注釈して文字列のベクタが欲しいの 
だと指定しています。 Rust において、型を注釈しなければならない頻度は非常に少ないのですが、 
collect はよく確かに注釈が必要になる一つの関数なのです。コンパイラには、あなたが欲している 
コレクションの種類が推論できないからです。 

最後に、デバッグ整形機の：？を使用してベクタを出力しています。弓 I 数なしでコードを走らせてみ 
て、それから引数二つで試してみましょう： 

$ cargo run 
-_sm p -- 

[" target / debug / mimgreo "] 

$ cargo run needle haystack 
-- snip -- 

[" target / debug / minigrep ", " needle ", " haystack "] 

ベクタの最初の値は 11 tar * get / debug / minigrep n であり、これはバイナリの名前であることに気付い 
てください。これは c の引数リストの振る舞いと合致し、実行時に呼び出された名前をプログラム 
に使わせてくれるわけです。メッセージで出力したり、プログラムを起動するのに使用されたコマン 
ドラインエイリアスによってプログラムの振る舞いを変えたい場合に、プログラム名にアクセスする 
のにしばしば便利です。ですが、この章の目的には、これを無視し、必要な二つの引数のみを保存し 
ます。 
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12.1.3 引数の値を変数に保存する 

引数のベクタの値を出力すると、プログラムはコマンドライン引数として指定された値にアクセス 
できることが説明されました。さて、プログラムの残りを通して使用できるように、二つの引数の値 
を変数に保存する必要があります。それをしているのがリスト 12-2 です。 

ファイル名： src/main.rs 
use std :: env : 
fn mann () { 

let args : Vec < String > = env : : args (). collect (); 

let query = & args [1]; 

let filename = & args [2]; 

// {} を探しています 

println! ("Searching for {}" , query ); 

// {} というファイルの 中 

println! ("In file {}" , filename ); 

} 

リスト 12-2: クエリ引数とファイル名引数を保持する変数を生成 

ベクタを出力した時に確認したように、プログラム名がベクタの最初の値、 args [0] を占めている 
ので、添え字1から始めます。 nrim _ g 「 ep が取る最初の引数は、検索する文字列なので、最初の引数へ 
の参照を変数 query に置きました。2番目の引数はファイル名でしょうから、2番目の引数への参照 
は変数 filename に置きました。 

一時的にこれらの変数の値を出力して、コードが意図通りに動いていることを証明しています。再 
度このプログラムを test と sample . txt という引数で実行しましよう： 

$ cargo run test sampLe.txt 

Compiling mimgrep v 0.1.0 ( file :/// proiects / minigrep ) 

Finished dev [unoptimized + debuginfo ] target ( s ) in 0.0 secs 
Running ' target / debug/minigrep test sample . txt ' 

Searching for test 
In file sample.txt 


素晴らしい、プログラムは動作しています！必要な引数の値が、正しい変数に保存されています。 
後ほど、何らかの エラー 処理を加えて、 ユーザが 引数を提供しなかった場合など、可能性のある特定 
の エラー 状況に対処します；今は、そのような状況はないものと し、 代わりに ファイル 読み取り能力 
を追加することに取り組みます。 
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12.2 ファイルを読み込む 

では、 filename コマンドライン弓 I 数で指定されたファイルを読み込む機能を追加しましょう。ま 
ず、テスト実行するためのサンプルファイルが必要ですね： minigrep が動作していることを確かめる 
ために使用するのに最適なファイルは、複数行にわたって同じ単語の繰り返しのある少量のテキスト 
です。リスト 12-3 は、うまくいくであろうエミリー•ディキンソン (Emily Dickinson ) の詩です！ 
プロジェクトのルート階層に poem.txt というファイルを作成し、この詩「私は誰でもない！あな 
たは誰？」を入力してください。 

ファイル名： poem.txt 


I 'm nobodv ! Who are you i 
Are you nobody , too ? 

Then there's a pair of us - don't tell ! 
They'd banish us , you know . 


How dreary to be somebody ! 

How public , like a frog 

To tell your name the livelong day 

To an admiring bog ! 

私は誰でもない！あなたは誰？ 

あなたも誰でもないの？ 

なら、私たちは組だね、何も言わないで！ 

あの人たちは、私たちを追放するでしょう。わかりますよね？ 


誰かでいるなんて侘しいじゃない！ 

カエルみたいで公すぎるじゃない。 

自分の名を長い1日に告げるのなんて。 

感服するような沼地にね！ 

リスト 12-3: エミリー•ディキンソンの詩は、いいテストケースになる 

テキストを適当な場所に置いて、 src / main . rs を編集し、ファイルを開くコードを追加してくださ 
い。リスト 12-4 に示したようにですね。 

フアイル名： src / main.rs 

use std :: env ; 

use std :: fs : : File ; 

use std : : io : : prelude : 

fn main () { 

# let args : Vec < String > = env : : args (). collect (); 

# 

# let query = & args [1]; 

# let filename = & args [2]; 
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# 

# println! ("Searching tor {}" , query ) : 

// -- snip __ 

println! ("In file {}" , filename ); 

// ファイルが見つかりませんでした 

let mut f = File : : open ( tiLename ) . expect("file not found ") ; 

let mut contents = String : : new (); 
f . read _ to _ string(&mut contents ) 

// ファイルの読み込み中に問題がありました 
• expect ("something went wrong reading the file ") ; 

// テキストは \ n {} です 

println! ("With text : \ n {}" , contents ); 

} 

リスト 12-4: 第 2 引数で指定されたファイルの中身を読み込む 

最初に、もう何個か use 文を追記して、標準ライブラリの関係のある箇所を持ってきています：ファ 
イルを扱うのに std :: fs :: Fi le が必要ですし、 std :: i 〇: : prelude ::*はファイル入出力を含む入出 
力処理をするのに有用なトレイトを色々含んでいます。言語が一般的な初期化処理で特定の型や関数 
を自動的にスコープに導入するように、 std ::彳〇モジュールにはそれ独自の共通の型や関数の初期化 
処理があり、入出力を行う際に必要になるわけです。標準の初期化処理とは異なり、 std :: 切の初期 
化処理には明示的に use 文を加えなければなりません。 

mai n に3文を追記しました：一つ目が、 File : :open 関数を呼んで filename 変数の値に渡して、 
ファイルへの可変なハンドルを得る処理です。二つ目が、 contents という名の変数を生成して、可変 
で空の String を割り当てる処理です。この変数が、ファイル読み込み後に中身を保持します。三つ 
目が、ファイルハンドルに対して read _ to _ stri_ng を呼び出し、引数として contents への可変参照を 
渡す処理です。 

それらの行の後に、今回もファイル読み込み後に contents の値を出力する一時的な pri ntln ! 文を 
追記したので、ここまでプログラムがきちんと動作していることを確認できます。 

第1コマンドライン引数には適当な文字列（まだ検索する箇所は実装してませんからね）を、第2 
引数に poem . txt ファイルを入れて、このコードを実行しましょう： 

$ cargo run the poem.txt 

Compiling mimgrep v 0.1.0 ( file :/// proiects / mimgrep ) 

Finished dev [unoptimized + debuginfo ] target ( s ) in 0.0 secs 
Running ' target / debug/minigrep the poem . txt ' 

Searching for the 

In file poem.txt 

With text : 

I'm nobody ! Who are you ? 

Are you nobody , too ? 

Then there's a pair of us - don't tell ! 

They'd banish us , you know . 
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How dreary to be somebody! 

How public,like a frog 

To teiL your name the livelong day 

To an admiring bog! 

素晴らしい！コードがファイルの中身を読み込み、出力するようになりました。しかし、このコー 
ドにはいくつか欠陥があります。 main 関数が複数の責任を受け持っています：一般に、各関数がただ 
一つの責任だけを持つようになれば、関数は明確かつ、管理しやすくなります。もう一つの問題点は、 
できうる限りのエラー処理を怠っていることです。まだプログラムが小規模なので、これらの欠陥は 
大きな問題にはなりませんが、プログラムが大規模になるにつれ、それを綺麗に解消するのは困難に 
なっていきます。プログラムを開発する際に早い段階でリファタタングを行うのは、良い戦術です。 
リファクタリングするコードの量が少なければ、はるかに簡単になりますからね。次は、それを行い 
ましょ5。 

12.3 リファクタリングしてモジュール性とエラー処理を向上させる 

プログラムを改善するために、プログラムの構造と起こりうるエラーに対処する方法に関連する4 
つの問題を修正していきましょう。 

1 番目は、 main 関数が 2 つの仕事を受け持っていることです：引数を解析し、ファイルを開いてい 
ます。このような小さな関数なら、これは、大した問題ではありませんが、 main 内でプログラムを巨 
大化させ続けたら、 main 関数が扱う個別の仕事の数も増えていきます。関数が責任を受け持つごと 
に、正しいことを確認しにくくなり、テストも行いづらくなり、機能を壊さずに変更するのも困難に 
なっていきます。機能を小分けして、各関数が1つの仕事のみに責任を持つようにするのが最善です。 

この問題は、 2 杳目の問題にも結びついています： query と filename はプログラムの設定用変数で 
すが、 f や contents といった変数は、プログラムのロジックを担っています。 main が長くなるほど、 
スコープに 入れるべき変数も増えます。そして、 スコープ にある変数が増えれば、各々の目的を追う 
のも大変になるわけです。設定用変数を一つの構造に押し込め、目的を明瞭化するのが最善です。 

3番目の問題は、ファイルを開き損ねた時に expect を使ってエラーメッセージを出力しているの 
に、エラーメッセージが ファィルが見つかりませんでした としか表示しないことです。ファイルを開く 行為 
は、ファイルが存在しない以外にもいろんな方法で失敗することがあります：例えば、ファイルは存 
在するかもしれないけれど、開く権限がないかもしれないなどです。現時点では、そのような状況に 
なった時、「ファイルが見つかりませんでした」というエラーメッセージを出力し、これはユーザに間 
違った情報を与えるのです。 

4番目は、異なるエラーを処理するのに expect を繰り返し使用しているので、ユーザが十分な数の 
引数を渡さずにプログラムを起動した時に、問題を明確に説明しない「範囲外アクセス (index out 
ofbounds )」 というエラーが Rust から得られることです。エラー処理のコードが全て1箇所に存在 
し、将来エラー処理ロジックが変更になった時に、メンテナンス者が1箇所のコードのみを考慮すれ 
ばいいようにするのが最善でしょう。エラー処理コードが1箇所にあれば、 エン ドューザにとって意 
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味のあるメッセージを出力していることを確認することにもつながります。 

プロジヱクトをリファクタリングして、これら4つの問題を扱いましょう。 

12.3.1 バイナリプロジヱクトの責任の分離 

main 関数に複数の仕事の責任を割り当てるという構造上の問題は、多くのバイナリプロジェクトで 
ありふれています。結果として、 main が肥大化し始めた際にバイナリプログラムの個別の責任を分割 
するためにガイドラインとして活用できる工程を Rust コミニユティは、開発しました。この工程は、 
以下のような手順になっています： 

• プログラムを main . rs と lib . rs に分け、ロジックを lib . rs に移動する。 

• コマンドライン引数の解析ロジックが小規模な限り、 main . rs に置いても良い。 

• コマンドライン引数の解析ロジックが複雑化の様相を呈し始めたら、 main . rs から抽出して 
lib . rs に移動する。 

この工程の後に main 関数に残る責任は以下に限定される： 

• 引数の値でコマンドライン引数の解析ロジックを呼び出す 
• 他のあらゆる設定を行う 
• lib . rs の run 関数を呼び出す 
• run がエラーを返した時に処理する 

このパターンは、責任の分離についてです： main . rs はプログラムの実行を行い、そして、 lib.rs 
が手にある仕事のロジック全てを扱います。 main 関数を直接テストすることはできないので、この 
構造により、プログラムのロジック全てを lib . rs の関数に移すことでテストできるようになります。 
main . rs に残る唯一のコードは、読めばその正当性が評価できるだけ小規模になるでしょう。このエ 
程に従って、プログラムのやり直しをしましょう。 

12.3.1.1 引数解析器を抽出する 

引数解析の機能を main が呼び出す関数に抽出して、コマンドライン弓傲解析ロジックを src / lib.rs 
に移動する準備をします。リスト 12-5 に新しい関数 parse _ config を呼び出す mai n の冒頭部を示し、 
この新しい関数は今だけ src / main . rs に定義します。 

フ アイ ル名： src / main.rs 

fn mann () { 

let args : Vec < String > = env : : args (). collect (); 
let ( query , filename ) 


} 


// -- snip -- 


parse _ conrig (& args ); 
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fn parse _ conrig ( args : & [ Stnng ] ) -> (& str , & str ) { 
let query = & args [1]; 
let filename = & args [2]; 

( query , ti Lename ) 

} 

リスト 12-5: main から parse_config 関数を抽出する 

それでもまだ、コマンドライン引数をベクタに集結させていますが、 main 関数内で引数の値の添え 
字 1 を変数 query に、添え字 2 を変数 filename に代入する代わりに、べクタ全体を parse_config 
関数に渡しています。そして、 parse_config 関数にはどの弓 I 数がどの変数に入り、それらの値を main 
に返すというロジックが存在します。まだ main 内に query と filename という変数を生成しています 
が、もう main は、コマンドライン引数と変数がどう対応するかを決定する責任は持ちません。 

このやり直しは、私たちの小規模なプログラムにはやりすぎに思えるかもしれませんが、少しずつ 
段階的にリファクタリングしているのです。この変更後、プログラムを再度実行して、引数解析がま 
だ動作していることを実証してください。問題が発生した時に原因を特定する助けにするために頻繁 
に進渉を確認するのはいいことです。 

12.3.1.2 設定値をまとめる 

もう少し parse_config 関数を改善することができます。現時点では、タプルを返していますが、即 
座にタプルを分解して再度個別の値にしています。これは、正しい抽象化をまだできていないかもし 
れない兆候です。 

まだ改善の余地があると示してくれる他の徴候は、 parse_config の config の部分であり、返却し 
ている二つの値は関係があり、一つの設定値の一部にどちらもなることを暗示しています。現状では、 
一つのタプルにまとめていること以外、この意味をデータの構造に載せていません；この二つの値を 
1構造体に置き換え、構造体のフィールドそれぞれに意味のある名前をつけることもできるでしょう。 
そうすることで将来このコードのメンテナンス者が、異なる値が相互に関係する仕方や、目的を理解 
しやすくできるでしょう。 

注釈：この複雑型 （complex type ) がより適切な時に組み込みの値を使うアンチパターンを、 
primitive obsession (訳注：初めて聞いた表現。組み込み型強迫観念といったところだろう 
か）と呼ぶ人もいます。 

リスト 12-6 は、 parse_config 関数の改善を示しています。 

フアイル名： src / main.rs 


# use std :: env ; 

# use std :: rs : : File ; 

# 
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fn mann () { 

let args : Vec < Stn ng > = env : : args () . coilect (); 

let conng = parse _ conrig (& args ); 

println! ("Searching for {}" , config . query ); 
println! ("In file {}" , config . filename ); 

let mut f = File : : open ( config.rn Lename ). expect ("file not found ") ; 

// -- snip -- 

} 

struct Config { 

query : String , 
tiL ename : String , 

} 

fn parse _ conrig ( args : & [ String ] ) -> Config { 
let query = args [1]. clone (); 
let filename = args [2]. clone (); 

Config { query , filename } 

} 

リスト 12-6: parse_config をリファクタリングして Config 構造体のインスタンスを返す 

query と filenmae というフィールドを持つよう定義された Config という構造体を追加しました 0 
parse_config のシグニチヤは、これで Config 値を返すと示すようになりました。 parse_config の 
本体では、以前は args の String 値を参照する文字列スライスを返していましたが、今では所有す 
る String 値を含むように Config を定義しています。 main の args 変数は引数値の所有者であり、 
parse_config 関数だけに借用させていますが、これは Config が args の値の所有権を奪おうとした 
ら、 Rust の借用規則に違反してしまうことを意味します。 

String のデータは、多くの異なる手法で管理できますが、最も単純だけれどもどこか非効率的な手 
段は、値に対して clone メソッドを呼び出すことです。これにより、 Config インスタンスが所有する 
データの総コピーが生成されるので、文字列データへの参照を保持するよりも時間とメモリを消費し 
ます。ですが、データをクローンすることで、コードがとても素直にもなります。というのも、参照 
のライフタイムを管理する必要がないからです。つまり、この場面において、少々のパフォーマンス 
を犠牲にして単純性を得るのは、価値のある代償です。 

12.3.2 clone を使用する代償 

実行時 コストのために clone を使用して所有権問題を解消するのを避ける傾向が多くの 

Rustacean にあります。第13章で、この種の状況においてより効率的なメソッドの使用法を 



第 12 章入出カプロジェクト： コマンド ラインプログラムを構築する_257 

学ぶでしょう。ですがとりあえずは、これらのコピーをするのは1回だけですし、ファイル名 
とクエリ文字列は非常に小さなものなので、いくつかの文字列をコピーして進渉するのは良し 
としましょう。最初の通り道でコードを究極的に効率化しようとするよりも、ちょっと非効率 
的でも動くプログラムを用意する方がいいでしょう。もっと Rust の経験を積めば、最も効率 
的な解決法から開始することも簡単になるでしょうが、今は、 clone を呼び出すことは完璧に 
受け入れられることです。 

main を更新したので、 parse_config から返された Config のインスタンスを config という変数に 
置くようになり、以前は個別の query と filename 変数を使用していたコードを更新したので、代わ 
りに Config 構造体のフィールドを使用するようになりました。 

これで コードは query と filename が関連していることと、その目的がプログラムの振る舞い方を 
設定するということをより明確に伝えます。これらの値を使用するあらゆる コードは、 config インス 
タンスの 目的の名前を冠した フィールドに それらを発見することを把握しています。 


12.3.2.1 Config のコンストラクタを作成する 

ここまでで、コマンドライン引数を解析する責任を負ったロジッタを main から抽出し、 
parse _ config 関数に配置しました。そうすることで query と filename の値が関連し、その関係性が 
コードに載っていることを確認する助けになりました。それから Config 構造体を追加して query と 
filename の関係する目的を名前付けし、構造体のフィールド名として parse _ config 関数からその値 
の名前を返すことができています。 

したがって、今や parse _ config 関数の目的は Config インスタンスを生成することになったので、 
parse _ config をただの関数から Config 構造体に紐づく new という関数に変えることができます。こ 
の変更を行うことで、コードがより慣用的になります。 String などの標準ライブラリの型のインス 
タンスを、 String : : new を呼び出すことで生成できます。同様に、 parse _ config を Config に紐づく 
new 関数に変えれば、 Config : : new を呼び出すことで Config のインスタンスを生成できるようになり 
ます。リスト 12-7 が、行う必要のある変更を示しています。 

フアイル名： src / main.rs 

# use std :: env ; 

# 

fn mann () { 

let args : Vec < String > = env : : args (). collect (); 
let config = Coring : : new (& args ); 

// snip __ 

} 


# struct Config { 

# query : String, 

# filename : String, 
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# } 

# 

// __ snip 
impl Config i 

fn new(args : & [Stri ng] ) -> Conng { 
let query = args[1].clone(); 
let ti lename = args[2].clone(); 

Config { query, filename } 

} 

} 

リスト 12-7: parse_conf]’g を Config: : new に変える 

parse_config を呼び出していた main を代わりに Config: : new を呼び出すように更新しました 0 
parse_config の名前を new に変え、 impl ブロックに入れ込んだので、 new 関数と Config が紐づくよ 
うになりました。再度このコードをコンパイルしてみて、動作することを確かめてください。 

12.3.3 エラー 処理を修正する 

さて、エラー処理の修正に取り掛かりましょう。ベクタが2個以下の要素しか含んでいないときに 
args ベクタの添え字 1 か 2 にアクセスしようとすると、プログラムがパニックすることを思い出し 
てください。試しに引数なしでプログラムを実行してください。すると、こんな感じになります： 

^ cargo run 

Compiung mimgrep v0.1.0 (file:///pro]ects/mimgrep) 

Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs 
Running 'target/debug/minigrep' 
thread 'main' panicked at 'index out of bounds : the len is 1 
but the index is 1',src/main.rs:29:21 

( スレッド 'main 1 は、「境界外アクセス：長さは 1 なのに添え字も 1 です」でパニックしま 
した） 

note : Run with 'RUST_BACKTRACE=1' for a backtrace. 

境界外アクセス：長さは 1 なのに添え字も 1 です という行は、プログラマ向けのエラーメッセージです。エン 
ド ユーザが 起きたことと代わりにすべきことを理解する手助けにはならないでしよう。これを今修正 
しましよ5。 


12.3.3.1 エラーメッセージを改善する 

リスト 12-8 で、 new 関数に、添え字1と2にアクセスする前にスライスが十分長いことを実 
証するチェックを追加しています。スライスの長さが十分でなければ、プログラムはパニックし、 
境界外インデックスより もいいエラーメ ッ セージを表示します。 


ファイル名： src / main.rs 
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// --snip 

fn new(args : & [String」） -> Config i 
if args.len() < 3 { 

// 引数の数が足りません 
panic! ( n not enough arguments") ; 

} 

// --snip-- 

リスト 12-8: 引数の数のチェックを追加する 

このコードは、リスト 9-9 で記述した value 引数が正常な値の範囲外だった時に panic! を呼び出 
した Guess: :new 関数と似ています。ここでは、値の範囲を確かめる代わりに、 args の長さが少なく 
とも3であることを確かめていて、関数の残りの部分は、この条件が満たされているという前提のも 
とで処理を行うことができます。 args に 2 要素以下しかなければ、この条件は真になり、 panic! マ 
クロを呼び出して、即座にプログラムを終了させます。 

では、 new のこの追加の数行がある状態で、再度引数なしでプログラムを走らせ、エラーがどんな 
見た目か確かめましょう： 

$ cargo run 

Compiling mimgrep v0.1.0 (file:///proiects/mimgrep) 

Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs 
Running 'target/debug/minigrep' 

thread 'main' panicked at 'not enough arguments', src/main.rs:30:12 
(スレッド 1 mai n 1 は「引数が足りません」でパニックしました） 
note : Run with 'RUST_BACKTRACE=1' for a backtrace. 

この出力の方がマシです：これでエラーメッセージが合理的になりました。ですが、ユーザに与え 
たくない追加の情報も含まれてしまっています。おそらく、ここではリスト 9-9 で使用したテクニッ 
クを使用するのは最善ではありません： panic! の呼び出しは、第9章で議論したように、使用の問題 
よりもプログラミング上の問題により適しています。代わりに、第9章で学んだもう一つのテクニッ 
クを使用することができます。成功か失敗かを示唆する Result を返すことです。 

12.3 .3. 2 panic ! を呼び出す代わりに new から Result を返す 

代わりに、成功時には Config インスタンスを 含み、 エラー 時には問題に言及する Result 値を返す 
ことができます。 Config: :new が main と対話する時、 Result 型を使用して問題があったと信号を送 
ることができます。それから main を変更して、 panic !呼び出しが引き起こしていた thread 1 mai n 1 
と RUST_BACKTRACE に関する周囲の テキスト がない、 ユーザ 向けのより実用的な エラーに Err 列挙子 
を変換することができます。 

リスト 12-9 は、 Config: : new の戻り値に必要な変更と Result を返すのに必要な関数の本体を示し 
ています。 main も 更新するまで、これは コンパイルで きないことに注意してください。その更新は次 
のリストで行います。 
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フアイル名： src / mam.rs 

impl Config i 

fn new ( args : & [ String ] ) -> Result < Config , static str > { 
if args . len () < 3 { 

return Err("not enough arguments ") ; 

} 

let query = args[1].clone(); 
let Tilename = args [2]. clone() ; 

Ok (Config { query , filename }) 

} 

} 

リスト 12-9: Config : : new から Result を返却する 

new 関数は、これで、成功時には Config インスタンスを、エラー時には static str * を伴う Result 
を返すようになりました。第 10 章の「静的ライフタイム」節から &’ s tatic str * は文字列リテラルの 
型であることを思い出してください。これは、今はエラーメッセージの型になっています。 

new 関数の本体で 2 つ変更を行いました：十分な数の引数をユーザが渡さなかった場合に panic ! を 
呼び出す代わりに、今は Err 値を返し、 Config 戻り値を Ok に包んでいます。これらの変更により、 
関数が新しい型シグニチャに適合するわけです。 

Config : : new から Err 値を返すことにより、 main 関数は、 new 関数から返ってくる Result 値を処 
理し、エラー時により綺麗にプロセスから抜け出すことができます。 

12.3.3.3 Config : : new を呼び出し、エラーを処理する 
エラーケースを処理し、ユーザフレンドリーなメッセージを出力するために、 main を更新して、リ 
スト 12-10 に示したように Config : : new から返されている Result を処理する必要があります。ま 
た、 panic ! からコマンドラインツールを 0 以外のエラーコードで抜け出す責任も奪い取り、手作業で 
それも実装します。0以外の終了コードは、我々のプログラムを呼び出したプロセスにプログラムが 
エラー状態で終了したことを通知する慣習です。 

フアイル名： src / main.rs 

use std :: process ; 

fn main () { 

let args : Vec < String > = env : : args (). collect (); 

let conng = Config : : new (& args ). unwrap _ or _ else (| err | { 

// 引数解析時に問題 

println! ("Problem parsing arguments : {}" , err ); 
process :: exit (1); 


})； 
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// -- snip __ 

リスト 12-10： 新しい Config 作成に失敗したら、エラーコードで終了する 

このリストにおいて、以前には講義していないメソッドを使用しました： unwrap _ or _ else です。こ 
れは標準ライブラリで Result く T ， E > に定義されています。 unwrap _ or _ else を使うことで、 panic ! 
ではない何らか独自のエラー処理を定義できるのです。この Result が Ok 値だったら、このメソッ 
ドの振る舞いは unwrap に似ています： Ok が包んでいる中身の値を返すのです。しかし、値が Err * 値 
なら、このメソッドは、クロージャ内でコードを呼び出し、クロージャは私たちが定義し、引数とし 
て unwra P _ 0 し else に渡す匿名関数です。クロージャについては第13章で詳しく講義します。とりあ 
えず、 unwr * ap _ or _ else は、今回リスト 12-9 で追加した not enough arguments という静的文字列の 
Err の中身を、縦棒の間に出現する err 引数のクロージャに渡していることだけ知っておく必要があ 
ります。クロージャのコードはそれから、実行された時に err 値を使用できます。 

新規 use 行を追加して標準ライブラリから process をインポートしました。クロージャ内のエラー 
時に走るコードは、たった2行です： err の値を出力し、それから process :: exit を呼び出します 0 
process : : exit 関数は、即座にプログラムを停止させ、渡された数字を終了コードとして返します 0 
これは、リスト 12-8 で使用した panic ! ベースの 処理と似ていますが、もう余計な出力はされませ 
ん。試しましょつ： 

$ cargo run 

Compiling mimgrep v 0.1.0 ( file :/// proiects / minigrep ) 

Finished dev [unoptimized + debuginfo ] target ( s ) in 0.48 secs 
Running ' target / debug / minigrep ' 

Problem parsing arguments : not enough arguments 

素晴らしい！この出力の方が遥かにユーザに優しいです。 

12.3 .4 main からロジックを抽出する 

これで設定解析のリファクタリングが終了したので、プログラムのロジックに目を向けましょう。 
「バイナリプロジェクトの責任の分離」で述べたように、現在 main 関数に存在する設定のセットアッ 
プや エラー 処理に関わらない全てのロジックを保持することになる run という関数を抽出します。や 
り終わったら、 main は簡潔かつ視察で確かめやすくなり、他のロジック全部に対してテストを書くこ 
とができるでしよう。 

リスト 12-11 は、抜き出した run 関数を示しています。今は少しずつ段階的に関数を抽出する改善 
を行っています。それでも、 src / main . rs に関数を定義していきます。 

フアイル名： src / main.rs 


fn mann () i 
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// -- snip -- 

pnntln ! ("Searching for {}" , config . query ); 
println! ("In file {}" , config . filename ); 

run ( config ); 

} 

fn run ( config : Config ) { 

let mut f = File : : open ( config.rn Lename ). expect ("file not found ") ; 

let mut contents = Stri ng : : new (); 
f . read _ to _ string(&mut contents ) 

• expect ("something went wrong reading the file ") ; 

println! ("With text : \ n {}" , contents ); 

} 

// -- snip -- 

リスト 12-11: 残りのプログラムロジックを含む run 関数を抽出する 

これで run 関数は、ファイル読み込みから始まる main 関数の残りのロジック全てを含むようにな 
りました。この run 関数は、引数に Config インスタンスを取ります。 

12.3 .4.1 run 関数から エラー を返す 

残りのプログラムロジックが run 関数に隔離されたので、リスト 12-9 の Config : : new のように、 
エラー処理を改善することができます。 expect を呼び出してプログラムにパニックさせる代わりに、 
run 関数は、何か問題が起きた時に Result < T , E > を返します。これにより、さらにエラー処理周りの 
ロジックをユーザに優しい形で main に統合することができます。リスト 12-12 にシグニチャと run 
本体に必要な変更を示しています。 

フアイル名： src / main.rs 

use std :: error :: Error ; 

// -- snip -- 

fn run ( config : Config ) -> Result < (), Box く Error 〉〉 { 
let mut f = File :: open ( config . tiL ename )?; 

let mut contents = String : : new (); 
f . read _ to _ string(&mut contents )?; 


println! ("With text :\ n {}" , contents ); 


} 


0k(0) 
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リスト 12-12： run 関数を変更して Result を返す 

ここでは、3つの大きな変更を行いました。まず、 run 関数の戻り値を Resu 1 t <() ， Box < Error >> に 
変えました。この関数は、以前はユニット型、 （） を返していて、それを Ok の場合に返される値とし 
て残しました。 

エラー型については、トレイトオブジェクトの Box < Error > を使用しました（同時に冒頭で use 文に 
より、 std : : error : : Error をスコープに導入しています)。トレイトオブジェクトについては、第17 
章で講義します。とりあえず、 B 0 X < Er r 0 r > は、関数が Error トレイトを実装する型を返すことを意味 
しますが、戻り値の型を具体的に指定しなくても良いことを知っておいてください。これにより、ェ 
ラーケースによって異なる型のエラー値を返す柔軟性を得ます。 

2番目に、 expect の呼び出しよりも？演算子を選択して取り除きました。第9章で語りましたね。 
エラーでパニックするので はなく、 ？ 演算子は呼び出し元が処理できるように、現在の関数から ェ 
ラー 値を返します。 

3番目に、 run 関数は今、成功時に Ok 値を返すようになりました。 run 関数の成功型は、シグニ 
チャで （） と定義したので、ユニット型の値を Ok 値に包む必要があります。最初は、この 0 k (()) と 
いう記法は奇妙に見えるかもしれませんが、このように （） を使うことは、 run を副作用のためだけに 
呼び出していると示唆する慣習的な方法です；必要な値は返しません。 

このコードを実行すると、コンパイルは通るものの、警告が表示されるでしょう： 

warning : unused std :: result :: ResuLt which must be used 

( 警告：使用されなければならない ' std : : result : : Result ' が未使用です） 

-- > src / main . rs :18:5 

I 

18 | ruruconfig ) ; 

| 八八八八八八八八八八八八 

= note : #[ warn ( unused _ must _ use )] on by derault 

コンパイラは、コードが Result 値を無視していると教えてくれて、この Result 値は、エラーが発 
生したと示唆しているかもしれません。しかし、エラーがあったか確認するつもりはありませんが、 
コンパイラは、ここにエラー処理コードを書くつもりだったんじゃないかと思い出させてくれていま 
す！今、その問題を改修しましょう。 

12.3 .4. 2 main で run から返ってきたエラーを処理する 

リスト 12-10 の Config : : new に対して行った方法に似たテクニックを使用してエラーを確認し、扱 
いますが、少し違いがあります： 

フアイル名： src / main.rs 


fn mann () i 

II -- snip -- 
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pnntln ! ("searching for {}"， config . query ); 
println! ("In file {}" , config . filename ); 

it let Err ( e ) = run (conn g ) { 

println! ("Application error : {}" , e ); 

process :: exit ( l ) ; 

} 

} 

unwrap _ or _ else ではなく 、 i flet で run が Err 値を返したかどうかを確認し、そうなら process 
:: exit (1) を呼び出しています。 run 関数は、 Config : : new が Config インスタンスを返すのと同じよ 
うに unwrap したい値を返すことはありません。 run は成功時に （） を返すので、エラーを検知するこ 
とにのみ興味があり、〇でしかないので、 unwrap _ or _ else に包まれた値を返してもらう必要はない 
のです。 

if let と unwrap _ or _ else 関数の中身はどちらも同じです：エラーを出力して終了します。 

12.3.5 コー ドをライブラリク レー トに分割する 

ここまで minigrep は良さそうですね！では、テストを行え、 src / main.rs ファイルの責任が減ら 
せるように、 src / main.rs ファイルを分割し、一部のコードを src / lib.rs ファイルに置きましょう。 
main 関数以外のコード全部を src / main.rs から src / lib.rs に移動しましょう： 

- run 関数定義 
• 関係する use 文 

• Config の定義 

• Config : : new 関数定義 

src / lib.rs の中身にはリスト 12-13 に示したようなシグニチャがあるはずです（関数の本体は簡潔 
性のために省略しました)。リスト 12-14 で src / main.rs に変更を加えるまで、このコードはコンパ 
イルできないことに注意してください。 

ファイル名： src / lib.rs 

use std :: error :: Error ; 
use std :: fs :: File ; 
use std : : ] o :: prelude : 


pub struct Config { 
pub query : String , 
pub filename : String , 

} 


impl Config { 
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pub fn new ( args : & Otring 」） -> Result < Confi g， static str > i 
// -- strip __ 

} 


pub fn run(config: Config) -> Result< (), Box<Error>> { 

// --snip-- 

} 

リスト 12-13: confi ’ g と run を src / lib.rs に移動する 

ここでは、寛大に pub を使用しています： Config のフィールドと new メソッドと run 関数です。こ 
れでテスト可能な公開 API のあるライブラリクレートができました！ 

さて、 src / lib.rs に 移動した コー ドを src / main.rs の バイ ナリ クレー トの スコープに 持っていく 
必要があります。リスト 12-14 に示したようにですね。 

フアイル名： src / main.rs 

extern crate rmmgrep; 

use std :: env: 

use std :: process; 

use minigrep: : Config; 

fn main() { 

// --snip-- 

it let Err (e) = minigrep :: run(config) { 

// --snip 

} 

} 

リスト 12-14: mini grep クレートを src / main.rs のスコープに持っていく 

ライブラリクレートをパイナリクレートに持っていくのに、 extern crate mi nigrep を使用してい 
ます。それから use minigrep: :Config 行を追加して Config 型をスコープに持ってきて、 run 関数に 
クレート名を接頭辞として付けます。これで全機能が連結され、動くはずです。 cargo run でプログ 
ラムを走らせて、すべてがうまくいっていることを確かめてください。 

ふう！作業量が多かったですね。ですが、将来成功する準備はできています。もう、エラー処理は 
遥かに楽になり、コードのモジュール化もできました。ここから先の作業は、ほぼ src / lib . rs で完結 
するでしよう。 

古いコードでは大変だけれども、新しいコードでは楽なことをして新発見のモジュール性を活用し 
ましよう：テストを書くのです！ 
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12.4 テスト駆動開発でライブラリの機能を開発する 

今や、ロジックを src / lib . rs に抜き出し、弓 I 数集めと エラー 処理を src / main . rs に残したので、 
コードの核となる機能のテストを書くのが非常に容易になりました。いろんな引数で関数を直接呼び 
出し、コマンドラインからバイナリを呼び出す必要なく戻り値を確認できます。ご自由に Config::new 
や run 関数の機能のテストは、ご自身でお書きください。 

この節では、テスト駆動開発 （ TDD ) 過程を活用して minigrep プログラムに検索ロジックを追加し 
ます。このソフトウヱア開発テクニックは、以下の手順に従います： 

1. 失敗するテストを書き、走らせて想定通りの理由で失敗することを確かめる。 

2. 十分な量のコードを書くか変更して新しいテストを通過するようにする。 

3. 追加または変更したばかりのコードをリファクタリングし、テストが通り続けることを確認 
する。 

4. 手順1から繰り返す！ 

この過程は、ソフトウヱアを書く多くの方法のうちの一つに過ぎませんが、 TDD によりコードデザ 
インも駆動することができます。テストを通過させるコードを書く前にテストを書くことで、過程を 
通して高いテストカバー率を保つ助けになります。 

実際にクエリ文字列の検索を行う機能の実装をテスト駆動し、クエリに合致する行のリストを生成 
します。この機能を search という関数に追加しましょう。 

12.4.1 失敗するテストを記述する 

もう必要ないので、プログラムの振る舞いを確認していた printin! 文を src / lib . rs と 
src / main . rs から削除しましょう。それから src / lib . rs で、テスト関数のある test モジュールを追 
加します。第 11 章のようにですね。このテスト関数が search 関数に欲しい振る舞いを指定します: 
クエリとそれを検索するテキストを受け取り、クエリを含む行だけをテキストから返します。リスト 
12-15 にこのテストを示していますが、まだ コンパイルは 通りません。 

ファイル名： src / lib.rs 

# fn search く ， a> (querv : &str , contents : &'a str) -> Vec<&' a str> { 

# vec! [] 

# } 

# 

# [cfg(test)] 
mod test { 

use super: ; 


#[test] 

fn one_result() { 
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let query = "duct 1 ': 

// Rust は 

// 安全で速く生産性も高い。 

// 3 つ選んで。 

let contents = "\ 

Rust: 

safe, fast, productive. 

Pick three." ; 

assert_eq! ( 

vec! ["safe, fast, productive. "] , 
search(query, contents) 

)； 

> 

> 

リスト 12-15： こうだったらいいなという search 関数の失敗するテストを作成する 

このテストは、 " duct .” という文字列を検索します。検索対象の文字列は3行で、うち1行だけ 
が’' duct .” を含みます。 search 関数から返る値が想定している行だけを含むことをアサーシヨンし 
ます。 

このテストを走らせ、失敗するところを観察することはできません。このテストはコンパイルも 
できないからです：まだ search 関数が存在していません！ゆえに今度は、空のベクタを常に返す 
search 関数の定義を追加することで、テストをコンパイルし走らせるだけのコードを追記します。リ 
スト 12-16 に示したようにですね。そうすれば、テストはコンパイルでき、失敗するはずです。なぜ 
なら、空のベクタは、 " safe , fast , productive •"という行を含むベクタとは合致しないからです。 

ファイル名： src / lib.rs 

pub rn search く ， a>(query : &str , contents : &' a str) -> Vec<&' a str> { 
vec! [] 

} 

リスト 12-16： テストがコンパイルできるのに十分なだけ search 関数を定義する 


明不的なライフタイムの 1 a が search のシクニチヤで定義され、 contents 引数と民り値で使用され 
ていることに気付いてください。第10章からライフタイム仮引数は、どの実引数のライフタイムが 
戻り値のライフタイムに関連づけられているかを指定することを思い出してください。この場合、返 
却されるべクタは、 ( query 引数ではなく） contents 引数のスライスを参照する文字列スライスを含む 
べきと示唆しています。 

言い換えると、コンパイラに search 関数に返されるデータは、 search 関数に contents 引数で渡 
されているデータと同期間生きることを教えています。これは重要なことです！スライスに参照さ 
れるデータは、参照が有効になるために有効である必要があるのです；コンパイラが contents ではな 
く query の文字列スライスを生成すると想定してしまったら、安全性チヱックを間違って行うことに 
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なってしまいます。 

ライフタイム注釈を忘れてこの関数をコンパイルしようとすると、こんなエラーが出ます : 


error[E 010 6] : missing liretime specifier 
(エラー： ライフタイム指定子が欠けています） 

-- > src/lib.rs:5 :51 

I 

5 | oub fn search(query : &str, contents : &str) -> Vec<&str> i 

| a expected litetime 


parameter 

I 

=help : this function's return type contains a borrowed value, but the 
signature does not say whether it is borrowed from 'query' or 'contents' 

( 助言：この関数の戻り値は、借用された値を含んでいますが、シグニチヤにはそれ 


が、 


query' か ' contents' から借用されたものであるかが示されていません） 


コンパイ ラには、二つの引数のどちらが必要なのか知る由がないので、教えてあげる必要があるので 
す。 contents がテキストを全て含む引数で、合致するそのテキストの一部を返したいので 、 contents 
がライフタイム記法で戻り値に関連づくはずの弓 I 数であることをプログラマは知っています。 

他のプログラミング言語では、シグニチャで引数と戻り値を関連づける必要はありません。これは 
奇妙に思えるかもしれませんが、時間とともに楽になっていきます。この例を第 10 章、「ライフタイ 
ムで参照を有効化する」節と比較したくなるかもしれません。 

さあ、テストを実行しましょう： 


$ cargo test 

Compiling mimgrep v0.1.0 (ri le:///projects/rmmgrep) 

--warm* ngs-- 

Finished dev [unoptimized + debuginfo] target(s) in 0.43 secs 
Running target/debug/deps/minigrep-abcabcabc 

running 1 test 

test test::one_result ... FAILED 
failures: 

- test::one_result stdout - 

thread 'test::one_result' panieked at 'assertion failed: '(left == 

right)' 

left : '["safe, fast, productive., 
right: src/lib.rs:48:8 

note : Run with 'RUST_BACKTRACE=1' for a backtrace. 


failures : 

test :: one_result 

test result : FAILED. 0 passed;1 failed; 0 ignored; 0 measured; 0 riLtered out 
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error: test Tailed ， to rerun oass '--lib 1 
素晴らしい。テストは全く想定通りに失敗しています。テストが通るようにしましょう！ 

12.4.2 テストを通過させるコードを書く 

空のベクタを常に返しているために、現状テストは失敗しています。それを修正し、 search を実装 
するには、プログラムは以下の手順に従う必要があります： 

• 中身を各行ごとに繰り返す。 

• 行にクエリ文字列が含まれるか確認する。 

• するなら、それを返却する値のリストに追加する。 

• しないなら、何もしない。 

• 一致する結果のリストを返す。 

各行を繰り返す作業から、この手順に順に取り掛かりましょう。 

12.4 .2.1lines メソッドで各行を繰り返す 

Rust には、文字列を行ごとに繰り返す役立つメソッドがあり、利便性のために lines と名付けら 
れ、 リスト 12-17 のように動作します。まだ、これは コンパイル できないことに注意してください。 

ファイル名： src/lib.rs 

oub rn search く ， a>(query : &str , contents : &'a str) -> Vec<&' a str> { 
for line in contents•lines() { 

// 行に対して何かする 
// do something with line 



リスト 12-17: contents の各行を繰り返す 

lines メソッドはイテレータを返します。イテレータについて詳しくは、第13章で話しますが、 
リスト 3-5 でこのようなイテレータの使用法は見かけたことを思い出してください。そこでは、イテ 
レータに for ループを使用してコレクションの各要素に対して何らかのコードを走らせていました。 

12.4.2.2 クエリを求めて各行を検索する 

次に現在の行がクエリ文字列を含むか確認します。幸運なことに、文字列にはこれを行ってくれる 
contains という役に立つメソッドがあります！ search 関数に 、 contai ns メソッドの呼び出しを追 
加してください。リスト 12-18 のようにですね。それでもまだコンパイルできないことに注意してく 
ださい。 
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ファイル名： src / lib.rs 

pub fn search く ， a>(query : &str , contents : &'a str) -> Vec<&' a str> i 
for line in contents.I t nes() { 
ir line•contains(query) { 

// do something with line 



} 

リスト 12-18 ： 行が query の文字列を含むか確認する機能を追加する 

12.4.2.3 合致した行を保存する 

また、クエリ文字列を含む行を保存する方法が必要です。そのために、 for ループの前に可変なベ 
クタを生成し 、 push メソッドを呼び出して line をべクタに保存することができます。 for ループの 
後でべクタを返却します。リスト 12-19 のようにですね。 

ファイル名： src/lib.rs 

oub rn search く ， a>(query : &str , contents : &' a str) -> Vec<&' a str> { 
let mut results = Vec :: new(); 

for line in contents•lines() { 
if line•contains(query) { 
results.push(line); 

} 

} 


results 

} 

リスト 12-19: 合致する行を保存したので、返すことができる 

これで search 関数は、 query を含む行だけを返すはずであり、テストも通るはずです。テストを実 
行しましよ5: 


5 cargo test 
--smp-- 
runmng 1 test 

test test::one_result ... ok 

test result : ok.1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out 
テストが通り、動いていることがわかりました！ 

ここで、テストが通過するよう保ったまま、同じ機能を保持しながら、検索関数の実装をリファク 
タリングする機会を考えることもできます。検索関数のコードは悪すぎるわけではありませんが、イ 
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テレータの有用な機能の一部を活用していません。この例には第13章で再度触れ、そこでは、イテ 
レータをより深く探究し、さらに改善する方法に目を向けます。 


12.4.2.4 run 関数内で search 関数を使用する 
search 関数が動きテストできたので、 run 関数から search を呼び出す必要があります。 config. 
query の値と、フアイルから run が読み込む contents の値を search 関数に渡す必要があります。そ 
れから run は、 search から返ってきた各行を出力するでしょう： 

ファイル名： src / lib.rs 


pub fn run (conn g: Conn g) -> Result< (), Box< ヒ rror>> { 
let mut f = File: :open(config.filename)?; 

let mut contents = String: : new(); 
f. read_to_string(&mut contents)?; 

for line in search(&config.query, &contents) { 
println! ("{}" ,line); 

} 

0k(0) 

} 

それでも for ■ループで search から各行を返し、出力しています 0 

さて、プログラム全体が動くはずです！試してみましょう。まずはエミリー•ディキンソンの詩か 
ら、ちょうど 1 行だけを返すはずの言葉から 。” frog” です： 

$ cargo run frog poem.txt 

Compiling mimgrep v0.1.0 ^fnle:///projects/immgrep) 

Finished dev [unoptimized + debuginfo] target(s) in 0.38 secs 
Running 'target/debug/minigrep frog poem.txt' 

How public, like a frog 

かっこいい！今度は、複数行にマッチするであろう言葉を試しましょう。 ’’body” とかね： 

$ cargo run bodv poem.txt 

Finished dev [unoptimized + debuginfo] target(s)in 0.0 secs 
Running 'target/debug/minigrep body poem.txt' 

I’m nobody! Who are you? 

Are you nobody, too? 

How dreary to be somebody! 


そして最後に、詩のどこにも現れない単語を探したときに、何も出力がないことを確かめましょ 

つ。 ’’ monomorphization ” などね： 

$ cargo run monomorphization poem.txt 

Finished dev [unoptimized + debuginfo] target(s)in 0.0 secs 
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Running 'target/debug/immgrep monomorphization poem.txt 

最高です！古典的なツールの独自のミニバージョンを構築し、アプリケーションを構造化する方法 
を多く学びました。また、ファイル入出力、ライフタイム、テスト、コマンドライン引数の解析につ 
いても、少し学びました。 

このプロジェクトをまとめ上げるために、環境変数を扱う方法と標準 エラー 出力に出力する方法を 
少しだけデモします。これらはどちらも、コマンドラインプログラムを書く際に有用です。 

12.5 環境変数を取り扱う 

おまけの機能を追加して mini grep を改善します：環境変数でユーザがオンにできる大文字小文字 
無視の検索用のオプションです。この機能をコマンドラインオプションにして、適用したい度にユー 
ザが入力しなければならないようにすることもできますが、代わりに環境変数を使用します。そうす 
ることでユーザは1回環境変数をセットすれば、そのターミナルセッションの間は、大文字小文字無 
視の検索を行うことができるようになるわけです。 

12.5.1 大文字小文字を区別しない search 関数用に失敗するテストを書く 

環境変数がオンの場合に呼び出す search_case_insensitive 関数を新しく追加したいです。テ 
スト駆動開発の過程に従い続けるので、最初の手順は、今回も失敗するテストを書くことです。 
新しい sea rch_case_i nsensi ti ve 関数用の新規テストを追加し、古いテストを one_ result から 
ca Se _ SenS iti_ve に名前変更して、二つのテストの差異を明確化します。リスト 12-20 に示したよう 
にですね。 

ファイル名： src / lib.rs 


# ictg(test)] 
mod test i 

use super: ; 


#[test] 

fn case_sensitive() { 
let query = "duct" ; 

// Rust 

// 安全かつ高速で生産的 
//三つを選んで 
//ガムテープ 

let contents = "\ 

Rust: 

sate, fast, oroductnve. 

Pick three. 

Duct tape." ; 


assert_eq! ( 
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vec ! ["sate, fast, productive . ’'」 ， 
search(auery, contents) 

)； 

} 


#[test] 

fn case_insensitive() { 
let query = " rllsT" ; 

// ( 最後の行のみ） 

// 私を信じて 

let contents = "\ 

Rust: 

safe, fast, productive. 

Pick three. 

Trust me." ; 

assert_eq! ( 

vec! ["Rust: " , "Trust me. "] , 

search_case_insensitive(query, contents) 

)； 

> 

> 

リスト 12-20: 追加しようとしている大文字小文字を区別しない関数用の失敗するテストを新しく 
追加する 


古いテストの contents も変更していることに注意してください。大文字小文字を区別する検索を 
行う際に、 "duct" というクエリに合致しないはずの大文字 D を使用した" Duct tape" (ガムテープ) 
という新しい行を追加しました。このように古いテストを変更することで、既に実装済みの大文字小 
文字を区別する検索機能を誤って壊してしまわないことを保証する助けになります。このテストはも 
う通り、大文字小文字を区別しない検索に取り掛かっても通り続けるはずです。 

大文字小文字を区別しない検索の新しいテストは、クエリに” rUsT ” を使用しています。追加直前 
の search_case_insensitive 関数では、 ” rUsT ” というクエリは、両方ともクエリとは大文字小文字 
が異なるのに、大文字 R の’’ Rust :” を含む行と、 “Trust me.” という行にもマッチするはずです。こ 
れが失敗するテストであり、まだ search_case_i nsensi tive 関数を定義していないので、コンパイル 
は失敗するでしょう。リスト 12-16 の search 関数で行ったように空のベクタを常に返す実装の骨格 
を追加して、ご自由にテストがコンパイルされ、失敗する様を確認してください。 

12.5 .2 sea rch _ case_i nsensi ti ve 関数を実装する 

search_case_i nsensi ti ve 関数は、リスト 12-21 に示しましたが、 search 関数とほぼ同じです。哨 
一の違いは、 query と各 line を小文字化していることなので、入力引数の大文字小文字によらず、行 
がクエリを含んでいるか確認する際には、同じになるわけです。 


ファイル名： src / lib.rs 
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pub rn search _ case _ insensitive く ， a > Qquery : & str , contents : &'a str ) -> Vec<&' a 

str > { 

let query = query . to _ lowercase (); 

let mut results = Vec :: new (); 

for line in contents . lines () { 

if line . to _ lowercase (). contains (& query ) { 
results . push ( line ); 

} 

} 

results 

} 

リスト 12-21: 比較する前にクエリと行を小文字化するよう、 searxh _ case _ insensitive 関数を定 
義する 

まず、 query 文字列を小文字化し、同じ名前の覆い隠された変数に保存します。ユーザのクエリが 
" rust " や" RUST " 、 " Rust "、" rUsT " などだったりしても、 " rust " であり、大文字小文字を区別しな 
いかのようにクエリを扱えるように、 to _ lowercase をクエリに対して呼び出すことは必須です。 

query は最早、文字列スライスではなく Stri ng であることに注意してください。というのも、 
to _ lowercase を呼び出すと、既存のデータを参照するというよりも、新しいデータを作成するからで 
す。例として、クエリは” rUsT ” だとしましょう：その文字列スライスは、小文字の u や t を使えるよ 
うに含んでいないので、 " rust " を含む新しい String のメモリを確保しなければならないのです。今、 
contai ns メソッドに引数として query を渡すと、アンド記号を追加する必要があります 。 contai ns 
のシグニチャは、文字列スライスを取るよう定義されているからです。 

次に、各 line が query を含むか確かめる前に to _ lowercase の呼び出しを追加し、全文字を小文字 
化しています。今や line と query を小文字に変換したので、クエリが大文字であろうと小文字であ 
ろうとマッチを検索するでしょう。 

この実装がテストを通過するか確認しましょう： 

running 2 tests 

test test :: case_insensitive ... ok 

test test :: case_sensitive ... ok 

test result : ok . 2 passed ; 0 failed ; 0 ignored ; 0 measured ; 0 tiL tered out 

素晴らしい！どちらも通りました。では、 run 関数から新しい search _ case _ insensitive 関数を 
呼び出しましょう。1番目に大文字小文字の区別を切り替えられるよう、 Config 構造体に設定オプ 
シヨンを追加します。まだどこでも、この フィールドの 初期化をしていないので、追加するとコンパ 
イルエラ ーが 起きます： 


ファイル名： src / lib.rs 
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pub struct Config { 
pub query : String, 
pub filename : String, 
pub case_sensitive : bool , 

} 

論理値を持つ case_sensitive フィールドを追加したことに注意してください。次に、 run 関数に、 
case_sensitive フイールドの値を雍認し、 search 関数か search_case_i nsensi ti ve 関数を呼ぶかを 
決定するのに使ってもらう必要があります。リスト 12-22 のようにですね。それでも、これはまだコ 
ンパイルできないことに注意してください。 

ファイル名： src / lib.rs 

# use std :: error :: Error ; 

# use std :: fs :: Fi le; 

# use std: :] 〇 :: prelude: 

# 

# fn search く ， a>(querv: &str , contents : &'a str) -> Vec<&' a str> { 

# vec! [] 

# } 

# 

# pub fn search_case_insensitive く ， a>(query: &str , contents : &'a str) -> Vec<&' a 

str> { 

# vec! [] 

# } 

# 

# pub struct Config { 

# query : String, 

# filename: Stri ng, 

# case_sensitive : bool , 

# } 

# 

pub fn run(config: Config) -> Result< (), Box<Error>> { 
let mut f = File: :open(config.rn Lename)?; 

let mut contents = String: : new(); 
f.read_to_string(&mut contents)?; 

let results = if config.case_sensitive { 
search(&contTg.query, &contents) 

} else { 

search_case_insensitive(&config.query, &contents) 

}； 

for line in results { 

println !("{}" ， line); 

} 

Ok(0) 

} 
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リスト 12-22: config.case_sensitive の値に基づいて search か search_case_insensitive を呼 
び出す 

最後に、環境変数を確認する必要があります。環境変数を扱う関数は、標準ライブラリの env モ 
ジュールにあるので、 use std : : env; 行で Src / lib . rS の冒頭でそのモジュールを スコー プに持つてく 
る必要があります。そして、 env モジュールから var* 関数を使用して CASE_INSENSITIVE とぃう環境 
変数のチェックを行ぃます。リスト 12-23 のようにですね。 

ファイル名： src / lib.rs 

use std :: env : 

# struct Contig { 

# query : String, 

# filename: String, 

# case_sensitive : bool , 

# } 

// --snip-- 

impl Config { 

pub fn new(args : & [String] ) -> Result<Config, &' static str> { 

if args.len() < 3 { 

return Err("not enough arguments") ; 

} 

let query = args[1].clone(); 

let tiL ename = args[2].clone(); 

let case_sensitive = env: : var ("CASE_INSENSITIVE") .is_err(); 

Ok (Config { query, tiL ename, case_sensitive }) 

} 

} 

リスト 12-23： CASE_INSENSITIVE とぃう環境変数のチヱックを行う 

ここで、 case_sensitive とぃう新しぃ変数を生成してぃます。その値をセットするために、 env: : 
var 関数を呼び出し、 CASE_INSENSITIVE 環境変数の名前を渡してぃます。 env: :var 関数は、環境変 
数がセットされてぃたら、環境変数の値を含む Ok 列挙子の成功値になる Result を返します。環境変 
数がセットされてぃなければ、 Err 列挙子を返すでしょう。 

Result の is_err メソッドを使用して、 エラーで ありゆえに、セットされてぃなぃことを確認して 
ぃます。これは大文字小文字を区別する検索をすべきことを意味します。 CASE_INSENSITIVE 環境変数 
が何かにセットされてぃれば、 iierr は false を返し、プログラムは大文字小文字を区別しなぃ検索 
を実行するでしょう。環境変数の値はどうでもよく、セットされてぃるかどうかだけ気にするので、 
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unwrap や expect あるいは、他のここまで見かけた Result のメソッドではなく、 is_err をチェック 
しています。 

case_sensiti ve 変数の値を Config インスタンスに渡しているので、リスト 12-22 で実装したよう 
に、 run 関数はその値を読み取り、 search か sea rch_case_i nsensi ti ve を呼び出すか決定できるの 
です。 

試行してみましょう！まず、環境変数をセットせずにクエリは to でプログラムを実行し、この時 
は全て小文字で” to ” という言葉を含むあらゆる行が合致するはずです。 

$ cargo run to poem.txt 

Compiling mimgrep v0.1.0 (file:///proiects/mimgrep) 

Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs 
Running 'target/debug/minigrep to poem.txt' 

Are you nobody, too? 

How dreary to be somebody! 


まだ機能しているようです！では、 CASE_INSENSITIVE を 1 にしつつ、同じクエリの to でプログ 
ラムを実行しましょう。 

Power Shell を使用しているなら、1コマンドではなく、2コマンドで環境変数をセットし、プロ 
グラムを実行する必要があるでしょう： 

$ $env:CASE_INSENSITIVE=l 
$ cargo run to poem.txt 

大文字も含む可能性のある” to ” を含有する行が得られるはずです： 

$ CASE_INSENSITIVE=1 cargo run to poem.txt 

Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs 
Running 'target/debug/minigrep to poem.txt' 

Are you nobody, too? 

How dreary to be somebody! 

To tell your name the livelong day 
To an admiring bog! 

素晴らしい、 ’’TO” を含む行も出てきましたね！ minigrep プログラムはこれで、環境変数によって 
制御できる大文字小文字を区別しない検索も行えるようになりました。もうコマンドライン引数か、 
環境変数を使ってオプシヨンを管理する方法も知りましたね。 

引数と環境変数で同じ設定を行うことができるプログラムもあります。そのような場合、プログラ 
ムはどちらが優先されるか決定します。自身の別の鍛錬として、コマンドライン引数か、環境変数で 
大文字小文字の区別を制御できるようにしてみてください。片方は大文字小文字を区別するように 
セットされ、もう片方は区別しないようにセットしてプログラムが実行された時に、コマンドライン 
引数と環境変数のどちらの優先度が高くなるかを決めてください。 

std ::e nv モジュールは、環境変数を扱うもっと多くの有用な機能を有しています：ドキュメンテー 
シヨンを確認して、何が利用可能か確かめてください。 
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12.6 標準出力ではなく標準 エラーにエラー メ ッセー ジを書き込む 

現時点では、すべての出力を pHntln! 関数を使用して端末に書き込んでいます。多くの端末は 、2 
種類の出力を提供します：普通の情報用の標準出力 （ stdout ) とエラーメッセージ用の標準エラー出力 
(stderr) です。この差異のおかげで、ユーザは、エラーメッセージを画面に表示しつつ、プログラム 
の成功した出力をファイルにリダイレクトすることを選択できます。 

println! 関数は、標準出力に出力する能力しかないので、標準エラーに出力するには他のものを使 
用しなければなりません。 

12.6.1 エラーが書き込まれる場所を確認する 

まず、 minigrep に出力される中身が、代わりに標準エラーに書き込みたいいかなるエラーメッセー 
ジも含め、どのように標準出力に書き込まれているかを観察しましょう。意図的にエラーを起こしつ 
つ、ファイルに標準出カストリームをリダイレクトすることでそうします。標準エラーストリームは 
リダイレクトしないので、標準エラーに送られる内容は、すべて画面に表示され続けます。 

コマン ドラインプログラムは、エラーメッセージを標準エラー出力に送信していると期待されてい 
るので、標準出カストリームをファイルにリダイレクトしても、画面にエラーメッセージが見られま 
す。我々のプログラムは、現状、いい振る舞いをしていません：代わりにファイルにエラーメッセー 
ジ出力を保存するところを、目撃するところです！ 

この動作をデモする方法は 、> と標準出カストリームをリダイレクトする先のファイル名、 
output.txt でプログラムを走らせることによります。引数は何も渡さず、そうするとエラーが 
起きるはずです： 

$ cargo run > output.txt 

> 記法により、標準出力の中身を画面の代わりに output.txt に書き込むようシェルは指示されま 
す。画面に出力されると期待していたエラーメッセージは見られないので、ファイルに入っていると 
いうことでしょう。以下が output.txt が含んでいる内容です： 

Problem parsing arguments : not enough arguments 

そうです。エラーメッセージは標準出力に出力されているのです。このようなエラーメッセージは 
標準エラーに出力され、成功した状態のデータのみがファイルに残ると遥かに有用です。それを変更 
します。 


12.6.2 エラー を標準 エラー に 出力す る 

リスト 12-24 のコードを使用して、エラーメッセージの出力の仕方を変更します。この章の前で 
行ったリファクタリングのため、エラーメッセージを出力するコードはすべて 1 関数、 main にあり 
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ます。標準ライブラリは、標準エラーストリームに出力する印 Hntln! マクロを提供しているので、 
println! を呼び出してエラーを出力していた 2 箇所を代わりに eprintln! を使うように変更しま 
しょう。 

フアイル名： src/main.rs 

fn mann() { 

let args : Vec<String> = env: : args().collect(); 

let config = Coring: : new(&args) .unwrap_or_else( | err | { 
eprintln! ("Problem parsing arguments : {}" , err); 
process :: exit (1); 

})； 

it let Err (e) = minigrep::run(config) { 
eprintln! ("Application error: {}" , e); 

process :: exit (1); 

} 

} 

リスト 12-24: eprintln! を使って標準出力ではなく、標準エラーにエラーメッセージを書き込む 

println! を印 Hntln! に変えてから、再度同じようにプログラムを実行しましよう。引数なしか 
つ、標準出力を> でリダイレクトしてね： 

$ cargo run > output.txt 

Problem parsing arguments : not enough arguments 

これで、エラーは画面に見えつつ、 output . txt は何も含まなくなり、これはコマンドラインプロ 
グラムに期待する動作です。 

再度、標準出力をファイルにリダイレクトしてエラーは起こさない引数でプログラムを走らせま 
しよう。以下のようにですね： 

$ cargo run to poem.txt > output.txt 

ターミナルには出力は見られず、 output . txt に結果が含まれます： 

フアイル名： output.txt 

Are you nobodv, toor 
How dreary to be somebody! 


これは、もう成功した出力には標準出力を、エラー出力には標準エラーを適切に使用していること 
をデモしています。 
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12.7 まとめ 

この章では、 ここまでに 学んできた主要な概念の一部を念押しし 、 Rust で 入出力処理を行う方法を 
講義しました。コマンドライン引数、ファイル、環境変数、そしてエラー出力に印 Hntln! マクロを 
使用す ることで、もう、 コマンドラインアプリケーションを書く準備ができています。以前の章の概 
念を使用す ることで、 コードは うまく 体系化され、適切なデータ構造に効率的にデータを保存し、ェ 
ラーを うまく 扱い、よくテストされ るでしょう。 

次は、関数型言語に影響された Rust 機能を一部探究します：クロージャとイテレータです。 
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13； 


関数型言語の 機能： イテ レー タと クロー 
ジヤ 


Rust の設計は、多くの既存の言語やテクニックにインスピレーションを得ていて、その一つの大 
きな影響が関数型プログラミングです。関数型でのプログラミングには、しばしば、引数で渡したり、 
関数から関数を返したり、関数を後ほど使用するために変数に代入することで関数を値として使用す 
ることが含まれます。 

この章では、関数型プログラミングがどんなものであったり、なかったりするかという問題につい 
ては議論しませんが、代わりに関数型とよく言及される多くの言語の機能に似た Rust の機能の一部 
について議論しましょう。 

具体的には、以下を講義します： 

• クロージャ、変数に保存できる関数に似た文法要素 
• イテレータ、一連の要素を処理する方法 

• これら2つの機能を使用して第12章の入出カプロジェクトを改善する方法 
• これら2つの機能の パフォーマンス （ネタ バレ： 思ったよりも速いです） 

パターンマッチングや enum など、他の Rust の機能も関数型に影響されていますが、他の章で講 
義してきました。クロージャとイテレータをマスターすることは、慣用的で速い Rust コードを書く 
ことの重要な部分なので、この章を丸ごと捧げます。 

13.1 クロージャ：環境をキャブチャできる匿名関数 

Rust のクロージャは、変数に保存したり、引数として他の関数に渡すことのできる匿名関数です。 
ある場所でクロージャを生成し、それから別の文脈でクロージャを呼び出して評価することができま 
す。関数と異なり、呼び出されたスコープの値をクロージャは、キャブチャすることができます。こ 
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れらのクロージャの機能がコードの再利用や、動作のカスタマイズを行わせてくれる方法を模擬しま 
しょう。 

13.1.1 クロージャで動作の抽象化を行う 

クロージャを保存して後々使用できるようにするのが有用な場面の例に取り掛かりましょう。その 
過程で、クロージャの記法、型推論、トレイトについて語ります。 

以下のような架空の場面を考えてください：カスタマイズされたエクササイズのトレーニングプラ 
ンを生成するアプリを作る立ち上げにかかることになりました。バックエンドは Rust で記述され、 
トレーニングプランを生成するアルゴリズムは、アプリユーザの年齢や、 BMI 、 運動の好み、最近の 
トレーニング、指定された強弱値などの多くの要因を考慮します。実際に使用されるアルゴリズムは、 
この例では重要ではありません；重要なのは、この計算が数秒要することです。必要なときだけこのア 
ルゴリズムを呼び出し、1回だけ呼び出したいので、必要以上にユーザを待たせないことになります。 

リスト 13-1 に示した simulated_expensi ve _ cal _ culation 関数でこの仮定のアルゴリズムを呼び出 
すことをシミュレートし、この関数は calculating slowly と出力し、2秒待ってから、渡した数値 
をなんでも返します。 

フアイル名： src / main.rs 

use std :: thread ; 

use std: : time: : Duratnon; 

fn simuLated_expensive_calcuLation い ntensity: u32) -> u32 { 

// ゆっくり計算します 

println! ("calculating slowly... ; 

thread :: s Leep(Duration :: from_secs(2)); 

intensity 

} 

リスト 13-1: 実行に約 2 秒かかる架空の計算の代役を務める関数 

次は、この例で重要なトレーニングアプリの部分を含む main 関数です。この関数は、ユーザが卜 
レーニングプランを要求した時にアプリが呼び出すコードを表します。アプリのフロントエンドと相 
互作用する部分は、クロージャの使用と関係ないので、プログラムへの入力を表す値をハードコード 
し、その出力を表示します。 

必要な入力は以下の通りです： 

• ユーザの強弱値、これはユーザがトレーニングを要求して、低強度のトレーニングか、高強度 
のトレーニングがしたいかを示したときに指定されます。 

• 乱数、これはトレーニングプランにバリエーションを起こします。 

出力は、推奨されるトレーニングプランになります。リスト 13-2 は使用する main 関数を示してい 
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ます。 


フ アイ ル名： src/mam.rs 
fn mann() { 

let simulated_user_specified_value =10; 
let simulated_random_number = 7; 

generate_workout( 

simulated_user_specified_value, 
simulated_random_number 

)； 

} 

# fn generate_workout(iintensity : u32 , random_number: u32) {} 

リスト 13-2: ユーザ入力や乱数生成をシミュレートするハードコードされた値がある main 関数 

簡潔性のために、変数 simulated_user*_specified_value は 10 、変数 simulated_random_number 
は 7 とハードコードしました；実際のプログラムにおいては、強弱値はアプリの フロント エンドから 
取得し、乱数の生成には、第 2 章の数当てゲームの例のように、 rand クレートを使用するでしょう。 
main 関数は、シミュレートされた入力値とともに generate_workout 関数を呼び出します。 

今や文脈ができたので、アルゴリズムに取り掛かりましよう。リスト 13-3 の generate_workout 関 
数は、この例で最も気にかかるアプリのビジネスロジックを含んでいます。この例での残りの変更は、 
この関数に対して行われるでしょう： 

フ アイ ル名： src/main.rs 

# use std :: thread ; 

# use std: : time: : Duration; 

# 

# fn simulated_expensTve_ca iculation(num: u32) -> u32 { 

# println! ("calculating slowly 

# thread :: sleep(Duration :: from_secs(2)); 

# num 

# } 

# 

fn generate_workout い ntensity: u32 , random_number: u32) { 
if intensity < 25 { 


println! ( 

// 今日は {} 回腕立て伏せをしてください！ 

"Today, do {} pushups! 11 , 

simulated_expensive_calculation(intensity) 

)； 


println! ^ 

// 次に、 {} 回腹筋をしてください！ 
"Next, do {} si tups!" , 
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simulated_expensive_calculation(intensity) 

)； 

} else { 

if random_number == 3 { 

// 今日は休憩してください！水分補給を忘れずに！ 

println ! ("Take a break today! Remember to stav hydrated! 11 ); 
} else { 

println! ( 

// 今日は、 {} 分間走ってください！ 

"Today, run for {} minutes! 11 , 
simulated_expensi ve_calculation (i intensity) 

)； 

> 



リスト 13-3: 入力に基づいてトレーニングプランを出力するビジネスロジックと、 
simulated _ expensive_calculation 関数の呼び出し 

リスト 13-3 のコードには、遅い計算を行う関数への呼び出しが複数あります。最初の if ブロック 
が、 simu 1 ated _ expensive _ calculation を2回呼び出し、外側の else 内の if は全く呼び出さず、2 
番目の else ケースの内側にあるコードは1回呼び出しています。 

generate _ workout 関数の期待される振る舞いは、まずユーザが低強度のト レーニング （25 より小 
さい数値で表される）か、高強度のト レーニング （25 以上の数値）を欲しているか確認することです。 

低強度のトレーニングプランは、シミュレーションしている複雑なアルゴリズムに基づいて、多く 
の腕立て伏せや腹筋運動を推奨してきます。 

ユーザが高強度のトレーニングを欲していれば、追加のロジックがあります：アプリが生成した乱 
数がたまたま3なら、アプリは休憩と水分補給を勧めます。そうでなければ、ユーザは複雑なアルゴ 
リズムに基づいて数分間のランニングをします。 

この コードは 現在、ビジネスのほしいままに動くでしょうが、 データ サイエンス チー 
ムが、 simulated _ expensive _ calculation 関数を呼び出す方法に何らかの変更を加える必 
要があると決定したとしましょう。そのような変更が起きた時に更新を簡略化するため、 
si mulated_expensi ve _ calculation 関数を1回だけ呼び出すように、このコードをリファクタリン 
グしたいです。また、その過程でその関数への呼び出しを増やすことなく無駄に2回、この関数を現 
時点で呼んでいるところを切り捨てたくもあります。要するに、結果が必要なければ関数を呼び出し 
たくなく、それでも1回だけ呼び出したいのです。 

13.1.1.1 関数でリファクタリング 

多くの方法でトレーニングプログラムを再構築することもできます。1杳目に si mulated_expensi ve _ calcu'Lati on 
関数への重複した呼び出しを変数に抽出しようとしましょう。リスト 13-4 に示したように。 


フアイル名： src / mam.rs 
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# use std :: tnread ; 

# use std :: time: : Duration; 

# 

# rn s]mulated_expensive_calculation(num: u32) -> u32 { 

# println! ("calculating slowly 

# thread :: sleep(Duration :: from_secs(2)); 

# num 

# } 

# 

fn generate_workout(intensity : u32, random_number: u32) { 
let expensive.result = 

simulated_expensive_calculation(intensity); 

if intensity < 25 { 
println! ( 

"Today, do {} pushups! 11 , 
expensive.result 

)； 

println! ( 

"Next, do {} situps! M , 
expensive.result 

)； 

} else { 

if random_number == 3 { 

println! ("Take a break today! Remember to stay hydrated!"); 
} else { 

println! ( 

"Today, run for {} minutes! 11 , 
expensive_result 

)； 



リスト 13-4: 複数の simu 1 ated_expensi ve _ cal _ cu 1 ation の呼び出しを 1 箇所に抽出し、結果を 
expensive _ result 変数に保存する 

この変更により si mulated_expensi ve_calculati on の呼び出しが単~■化され、最初の if ブロック 
が無駄に関数を2回呼んでいた問題を解決します。不幸なことに、これでは、あらゆる場合にこの関 
数を呼び出し、その結果を待つことになり、結果値を全く使用しない内側の if ブロックでもそうし 
てしまいます。 

プログラムの1箇所でコードを定義したいですが、結果が本当に必要なところでだけコードを実行 
します。これは、クロージャのユースケースです！ 

13.1 .1.2 クロージャでリファクタリングして、コードを保存する 

if ブロックの前にいつも si mu 1 ated_expensi ve _ ca 1 cu 1 ati on 関数を呼び出す代わりに、クロー 
ジャを定義し、関数呼び出しの結果を保存するのではなく、そのクロージャを変数に保存できます。 
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リスト 13-5 のようにですね。 simulated_expensive_calculation の本体全体を実際に、ここで導入 
しているクロージャ内に移すことができます。 

フアイル名： src/main.rs 

# use std :: thread ; 

# use std: : time: : Duration; 

# 

let expensive_cLosure = |num| { 

println! ("calculating slowly... ; 
thread :: sleep(Duration :: from_secs(2)); 


# expensive_closure(5); 

リスト 13-5: クロ ^ ージャを定義し、 expensive_c 10 sure 変数に保存する 

クロ ^ ー ジャ定義が = に続き、変数 expensive_c 10 sure に代入されています。クロージャを定義する 
には、 1 組の縦棒から始め、その内部にクロージャの仮引数を指定します；この記法は、 Smalltalk や 
Ruby のクロージャ定義と類似していることから、選択されました。このクロージャには、 num という 
引数が 1 つあります： 2 つ以上引数があるなら、 Iparaml, param2| のように、カンマで区切ります。 

引数の後に、クロージャの本体を保持する波括弧を配置します（これはクロージャ本体が式一つな 
ら省略可能です ) 。波括弧の後、クロージャのお尻には、セミコロンが必要で、 let 文を完成させま 
す。クロージャ本体の最後の行から返る値 （ num) が、呼び出された時にクロージャから返る値になり 
ます。その行がセミコロンで終わっていないからです；ちょうど関数の本体みたいですね。 

この let 文は、 expensive_closure が、匿名関数を呼び出した 結果の 値ではなく、匿名関数の 定義 
を含むことを意味することに注意してください。コードを定義して、 1 箇所で呼び出し、そのコード 
を保存し、後々、それを呼び出したいがためにクロージャを使用していることを思い出してください ; 
呼び出したいコードは、現在、 expensive_c 10 sure に保存されています。 

クロージャが定義されたので、 if ブロックのコードを変更して、そのコードを実行するクロージャ 
を呼び出し、結果値を得ることができます。クロージャは、関数のように呼び出せます：クロージャ 
定義を含む変数名を指定し、使用したい引数値を含むかっこを続けます。リスト 13-6 に示したよう 
にですね。 

フアイル名： src / main.rs 

# use std :: thread ; 

# use std :: time: : Duration; 

# 

fn generate_workout い ntenslty: u32, random_number: u32) { 
let expensive_closure = |num| { 
println! ("calculating slowly 
thread :: sleep (Du rati on :: from_secs(2)); 


num 
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}； 


if intensitv < 25 { 
pnntln! ( 

"Today, do {} pushups! 11 , 
expensive_closure(intensity) 

)； 

println! ( 

"Next, do {} si tups!" , 
expensive_closure(intensity) 

)； 

} else { 

if random_number == 3 { 

println! ("Take a break today! Remember to stay hydrated! 11 ); 
} else { 

println! ( 

"Today, run for {} minutes ! 11 ， 
expensive_c 10 su re(intensity) 

)； 



リスト 13-6: 定義した expensi ve_closure を呼び出す 

今では、重い計算はたった 1 箇所でのみ呼び出され、その結果が必要なコードを実行するだけにな 
りました。 

ところが、リスト 13-3 の問題の一つを再浮上させてしまいました：それでも、最初の if ブロック 
でクロージャを 2 回呼んでいて、そうすると、重いコードを 2 回呼び出し、必要な分の 2 倍ユーザを 
待たせてしまいます。その if ブロックのみに属する変数を生成して、クロージャの呼び出し結果を 
保持するその if ブロックに固有の変数を生成することでこの問題を解消することもできますが、ク 
ロージャは他の解決法も用意してくれます。その解決策については、もう少し先で語りましょう。で 
もまずは、クロージャ定義に型注釈がない理由とクロージャに関わるトレイトについて話しましょう。 

13.1 .2 クロージャの型推論と注釈 

クロージャでは、 fn 関数のように引数の型や戻り値の型を注釈する必要はありません。関数では、 
型注釈は必要です。ユーザに露出する明示的なインターフヱイスの一部だからです。このインター 
フェイスを堅実に定義することは、関数が使用したり、返したりする値の型についてみんなが合意し 
ていることを保証するために重要なのです。しかし、クロージャはこのような露出するインターフェ 
イスには使用されません：変数に保存され、名前付けしたり、ライブラリの使用者に晒されることな 
く、使用されます。 

クロージャは通常短く、あらゆる任意の筋書きではなく、狭い文脈でのみ関係します。このような 
限定された文脈内では、コンパイラは、多くの変数の型を推論できるのに似て、引数や戻り値の型を 
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u32) -> u32 { x + 1 } 
u32| -> u32 { x + 1 } 
{ x + 1 } 
x + 1 


1 行目が関数定義を示し、 2 行目がフルに注釈したクロージャ定義を示しています。 3 行目は、ク 
ロージャ定義から型注釈を取り除き、 4 行目は、かっこを取り除いていて、かっこはクロージャの本 
体がただ 1 つの式からなるので、省略可能です。これらは全て、呼び出された時に同じ振る舞いにな 
る合法な定義です。 

クロージャ定義には、弓 I 数それぞれと戻り値に対して推論される具体的な型が一つあります。例え 
ば、リスト 13-8 に引数として受け取った値を返すだけの短いクロージャの定義を示しました。 この 
クロージャは、 この 例での目的以外には有用ではありません。 この 定義には、何も型注釈を加えてい 
ないことに注意してください：それから 1 回目に String を引数に、 2 回目に U32 を引数に使用してこ 
のクロージャを 2 回呼び出そうとしたら、エラーになります。 

フアイル名： src / main.rs 
let example closure = IxI x; 


頼もしく推論することができます。 

このような小さく、匿名の関数で型をプログラマに注釈させることは、煩わしくコンパイラがすで 
に利用可能な情報と、大筋で余分でしょう。 

変数のように、厳格に必要な以上に冗長になることと引き換えに、明示性と明瞭性を向上させたい 
なら、型注釈を加えることができます；リスト 13-5 で定義したクロージャに型を注釈するなら、リス 
卜 13-7 に示した定義のようになるでしょう。 

フアイル名： src/main.rs 

# use std :: thread ; 

# use std :: time: : Duration; 

# 

let expensTve_closure = |num: u32 1 -> u32 i 
println! ("calculating slowly... ; 
thread :: sleep(Duration: : from_secs(2)); 
num 

>； 

リスト 13-7 : クロージャの引数と戻り値の省略可能な型注釈を追加する 

型注釈を付け加えると、クロージャの記法は、関数の記法により酷似して見えます。以下が、引数 
に 1 を加える関数の定義と、同じ振る舞いをするクロージャの定義の記法を縦に比べたものです。空 
白を追加して、関連のある部分を並べています。これにより、縦棒の使用と省略可能な記法の量を除 
いて、クロージャ記法が関数記法に似てい ると ころを説明しています。 


X X XX 
II II -- 

12 3 4 

V V V V 


d d d d 
d d d d 
aaaa 


n e e e 
fill 
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let s = example_closure(Stnng: : f rom("hello") ) ; 
let n = example_closure(5); 


リスト 13-8: 2 つの異なる型で型が推論されるクロージャの呼び出しを試みる 


コンパイラは、 次の エラーを 返します: 


error[E0308] : mismatched types 
——> src/main.rs 


I 

| let n = example_closure(5); 


I 

integral variable 

I 

=note : expected type 'std: : string: : String' 
found type '{integer}' 


expected struct 'std: : string: : String', found 


String 値で example_c 10 sure を呼び出した最初の時点で、コンパイラは x とクロージャの戻り値 
の型を String と推論します。そして、その型が example_c 10 sure のクロージャに閉じ込められ、同 
じクロージャを異なる型で使用しようとすると、型エラーが出るのです。 


13.1.3 ジェネリック引数と Fn トレイトを使用してクロージャを保存する 

トレーニング生成アプリに戻りましょう。リスト 13-6 において、まだコードは必要以上の回数、重 
い計算のクロージャを呼んでいました。この問題を解決する一つの選択肢は、重いクロージャの結果 
を再利用できるように変数に保存し、クロージャを再度呼ぶ代わりに、結果が必要になる箇所それぞ 
れでその変数を使用することです。しかしながら、この方法は同じコードを大量に繰り返す可能性が 
あります。 

運のいいことに、別の解決策もあります。クロージャやクロージャの呼び出し結果の値を保持する 
構造体を作れるのです。結果の値が必要な場合のみにその構造体はクロージャを実行し、その結果の 
値をキャッシュするので、残りのコードは、結果を保存し、再利用する責任を負わなくて済むのです。 
このパターンは、メモ化 （ memoization ) または、遅延評価 （lazy evaluation ) として知っているか 
もしれません。 

クロージャを保持する構造体を作成するために、クロージャの型を指定する必要があります。構造 
体定義は、各フィールドの型を把握しておく必要がありますからね。各クロージャインスタンスには、 
独自の匿名の型があります：つまり、たとえ2つのクロージャが全く同じシグニチャでも、その型は 
それでも違うものと考えられるということです。クロージャを使用する構造体、 enum 、 関数引数を 
定義するには、第10章で議論したように、ジヱネリクスとトレイト境界を使用します。 

Fn トレイトは、標準ライブラリで用意されています。全てのクロージャは、そのトレイトのどれか 
を実装しています： Fn 、 FnMut または、 FnOnce です。「クロージャで環境をキャブチャする」節で、こ 
れらのトレイト間の差異を議論します；この例では、 Fn トレイトを使えます。 



第 13 章関数型言語の機能：イテレータとクロージャ 


290 


Fn トレイト境界への型を追加して、クロージャがこのトレイト境界を合致させるために持っていな 
ければならない引数と戻り値の型を表します。今回の場合、クロージャは、引数の型が U32 で、 U32 
を返すので、指定するトレイト境界は、 Fn(u32) -> u32 です。 

リスト 13-9 は、クロージャとオプションの結果値を保持する Cacher 構造体の定義を示してい 
ます。 


フアイル名： src / mam.rs 


struct し acher<T> 

where T : Fn(u32) -> u32 

{ 

calculation: T, 
value: 0ption<u32>, 

} 

リスト 13-9: クロージャを calculation に、オプシヨンの結果値を value に保持する Cacher 構造 
体を定義する 

Cacher 構造体には、ジェネリックな型 T の calculation フィールドがあります。 T に関するトレイ 
卜境界は、 Fn トレイトを使うことでクロージャであると指定しています。 calculation フィールドに 
保存したいクロージャは全て、 1 つの U32 引数 （ Fn の後の括弧内で指定されている）を取り、 U32 (-> 
の後に指定されている）を返さなければなりません。 

注釈：関数も3つの Fn トレイト全部を実装します。したいことに環境から値をキャブチャする 
ことが必要ないなら、 Fn トレイトを実装する何かが必要になるクロージャではなく、関数を使 
用できます。 

value フィールドの型は、 0 口 1: 彳〇 11<1|32> です。クロージャを実行する前に、 value は None になるで 
しょう。 Cacher を使用するコードがクロージャの結果を求めてきたら、その時点で Cacher はクロー 
ジャを実行し、その結果を value フィールドの Some 列挙子に保存します。それから、コードが再度 
クロージャの結果を求めたら、クロージャを再実行するのではなく、 Cacher は Some 列挙子に保持さ 
れた結果を返すでしょう。 

たった今解説した value フィールド周りのロジックは、リスト 13-10 で定義されています。 

フアイル名： src / main.rs 


# struct Cacner<T> 

# where T : Fn(u32) -> u32 

# { 

# calculation : T, 

# value : 0ption<u32>, 

# } 

# 

impl<T> Cacher く T> 
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where T : Fn(u32) -> u32 

{ 

fn new (.calculation : T; -> Cacher<T> { 
Cacher { 

calculation, 
value : None, 



fn value(&mut self, arg: u32) -> 1132 { 
match self .value { 

Some (v) => v ， 

None => { 

let v = (self .calculation)(arg); 
self .value = Some(v) ; 



リスト 13-10: Cacher のキャッシュ機構 

呼び出し元のコードにこれらのフィールドの値を直接変えてもらうのではなく、 Cacher に構造体の 
フィールドの値を管理してほしいので、これらのフィールドは非公開になっています。 

Cacher : : new 関数は、ジヱネリックな引数の T を取り、これは、 Cacher 構造体と同じトレイト境界 
を持つと定義しました。それから calculation フィールドに指定されたクロージャと、 value フィー 
ルドに None 値を保持する Cacher インスタンスを Cacher : : new は返します。まだクロージャを実行 
していないからですね。 

呼び出し元のコードがクロージャの評価結果を必要としたら、クロージャを直接呼ぶ代わりに、 
value メソッドを呼びます。このメソッドは、結果の値が self• value の Some に既にあるかどうか確 
認します；そうなら、クロージャを再度実行することなく Some 内の値を返します。 

self .value が None なら、コードは self • calculation に保存されたクロージャを呼び出し、結果 
を将来使えるように self .value に保存し、その値を返しもします 0 

リスト 13-11 は、リスト 13-6 の関数 generate_workout でこの Cacher 構造体を使用する方法を示 
しています。 

フアイル名： src/main.rs 

# use std :: thread ; 

# use std: : time: : Durati on; 

# 

# struct Cacher<T> 

# where T : Fn(u32) -> u32 

# { 

# calculation : T, 
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# value : 0ption<u32>, 

# } 

# 

# -impl<T> Cacher く T> 

# where T : Fn(u32) -> u32 

# { 

# fn new(calculation: T) -> Cacher<T> { 

# Cacher { 

# calculation, 

# value : None, 

# } 

# } 

# 

# fn value (&mut self, arg: u32) -> u32 { 

# match self .value { 

# Some(v) => v, 

# None => { 

# let v = (self .calculation)(arg); 

# self .value = Some(v) ; 

# v 

# }, 

# } 

# } 

# } 

# 

fn generate_workout(intensity : u32, random_number: u32) { 
let mut expensive.result = Cacher :: new(|num| { 
println! ("calculating slowly 
thread :: sleep (Durati on :: from_secs(2)); 


})； 


if intensity < 25 { 
println! ( 

"Today, do {} pushups! 11 , 
expensi ve_ result. value p intensity) 

)； 

println! ( 

"Next, do {} si tups!" , 

expensive_result.valuep ntensity) 

)； 

} else { 

if random_number == 3 { 

pri ntln! ("Take a break today! Remember to stay hydrated! 11 ); 
} else { 

println! ( 

"Today, run for {} minutes! 11 , 
expensive_result•value(intensity) 


} 


} 


} 


)； 
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リスト 13-11: generate _ workout 関数内で Cacher を使用し、キャッシュ機構を抽象化する 

クロージャを変数に直接保存する代わりに、クロージャを保持する Cacher の新規インスタンスを 
保存しています。そして、結果が必要な場所それぞれで、その Cacher インスタンスに対して value 
メソッドを呼び出しています。必要なだけ value メソッドを呼び出したり、全く呼び出さないことも 
でき、重い計算は最大でも1回しか走りません。 

リスト 13-2 の mai n 関数とともにこのプログラムを走らせてみてください〇 si mulated _ user_speci fi ed _ value 
と simulated _ random _ number 変数の値を変えて、いろんな if や else ブロックの場合全てで、 
calculating slowly は1回だけ、必要な時にのみ出現することを実証してください。必要以 
上に重い計算を呼び出さないことを保証するのに必要なロジックの面倒を Cacher は見るので、 
generate _ workout はビジネスロジックに集中できるのです。 

13.1 .4 Cacher 実装の限界 

値をキャッシュすることは、コードの他の部分でも異なるクロージャで行いたくなる可能性のある 
一般的に有用な振る舞いです。しかし、現在の Cacher の実装には、他の文脈で再利用することを困 
難にしてしまう問題が2つあります。 

1畨目の問題は、 Cacher インスタンスが、常に value メソッドの引数 arg に対して同じ値になると 
想定していることです。言い換えると、 Cacher のこのテストは、失敗するでしょう： 

# [ test ] 

fn ca L l _ wi th _ different _ values () { 
let mut c = Cacher :: new (| a | a ); 

let vl = c . value ( l ); 
let v 2 = c . value (2); 

assert _ eq ! ( v 2, 2); 

} 

このテストは、渡された値を返すクロージャを伴う Cacher インスタンスを新しく生成しています。 

この Cacher インスタンスに対して1という arg 値で呼び出し、それから2という arg 値で呼び出し、 

2という arg 値の value 呼び出しは2を返すべきと期待しています。 

このテストをリスト 13-9 とリスト 13-10 の Cacher 実装で動かすと、 asse 「 t _ eq からこんなメッ 
セージが出て、テストは失敗します： 


thread ' call _ with _ ditferent _ values ' panicked at 'assertion failed : (left == 
right )、 
left : ' 1 ', 

right : '2'', src / main.rs 

問題は、初めて c . value を 1 で呼び出した時に、 Cacher ■インスタンスは self . value に Some ( l ) を 
保存したことです。その後 value メソッドに何を渡しても、常に1を返すわけです。 
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単独の値ではなく、ハッシュマップを保持するように Cacher を改変してみてください。ハッシュ 
マップのキーは、渡される arg 値になり、ハッシュマップの値は、そのキーでクロージャを呼び出し 
た結果になるでしょう。 self .value が直接 Some か None 値であることを調べる代わりに、 value 関数 
はハッシュマップの arg を調べ、存在するならその値を返します。存在しないなら、 Cacher はクロー 
ジャを呼び出し、 arg 値に紐づけてハッシュマップに結果の値を保存します。 

現在の Cacher 実装の2畨目の問題は、引数の型に u32 を一つ取り、 u32 を返すクロージャしか受 
け付けないことです。例えば、文字列スライスを取り、 usize を返すクロージャの結果をキャッシュ 
したくなるかもしれません。この問題を修正するには、 Cacher 機能の柔軟性を向上させるためにより 
ジェネリックな引数を導入してみてください。 

13.1.5 クロージャで環境をキャプチャする 

トレーニング生成の例においては、クロージャをインラインの匿名関数として使っただけでした。 
しかし、クロージャには、関数にはない追加の能力があります：環境をキャブチャし、自分が定義さ 
れた スコープの 変数にアクセスできるのです。 

リスト 13-12 は、 eq Ua l _ to_x 変数に保持されたクロージャを囲む環境から x 変数を使用するク 
ロージャの例です。 

フアイル名： src / main.rs 

fn mann() { 
let x = 4; 

let equal_to_x = |z| z == x; 
let y = 4; 


assert! (equal_to_x(y)); 

} 

リスト 13-12: 内包するスコープの変数を参照するクロージャの例 

ここで、 x は equal_to_x の引数でもないのに、 equal_to_x が定義されているのと同じスコープで 
定義されている x 変数を eq U al_t 0 _x クロージャは使用できています。 

同じことを関数では行うことができません；以下の例で試したら、コードはコンパイルできません： 

フアイル名： src / main.rs 

fn mann() { 
let x = 4; 

fn equal_to_x(z: -i32) -> bool { z == x } 


let y = 4; 
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assert ! (. equal _ to_x ( y )) ; 

} 

エラーが 出ます： 

error [ E 0434] : can't capture dynamic environment in a fn item ; use the || { 

} closure form instead 

( エラー： fn 要素では動的な環境をキャブチャで きません； 代わりに|| { ... } の クロー 
ジャ形式を 

使用してください） 

-- > src / main.rs 

I 

4 | fn equal _ to _ x ( z : i 32) -> bool { z == x } 

I A 

コンパイラは、この形式はクロージャでのみ動作することさえも思い出させてくれています！ 

クロージャが環境から値をキャブチャすると、メモリを使用してクロージャ本体で使用できるよう 
にその値を保存します。このメモリ使用は、環境をキャブチャしないコードを実行するようなもっと 
一般的な場合には払いたくないオーバーへッドです。関数は、絶対に環境をキャブチャすることが許 
可されていないので、関数を定義して使えば、このオーバーヘッドを招くことは絶対にありません。 

クロージャは、3 つの 方法で環境から値をキャブチャでき、この方法は関数が引数を取れる3 つの 
方法に直に対応します：所有権を奪う、可変で借用する、不変で借用するです。これらは、以下のよ 
うに3 つの Fn トレイトでコード化されています： 

• FnOnce は、クロージャの環境として知られている内包されたスコープからキャブチャした変数 
を消費します。キャブチャした変数を消費するために、定義された際にクロージャはこれらの 
変数の所有権を奪い、自身にムーブするのです。名前のうち、 Once の部分は、このクロージャ 
は同じ変数の所有権を2回以上奪うことができないという事実を表しているので、1回しか呼 
ぶことができないのです。 

• FnMut は、可変で値を借用するので、環境を変更することができます0 

• Fn は、環境から値を不変で借用します。 

クロージャを生成する時、クロージャが環境を使用する方法に基づいて、コンパイラはどのトレ 
イトを使用するか推論します。少なくとも1回は呼び出されるので、全てのクロージャは FnOnce を 
実装しています。キャブチャした変数をムーブしないクロージャは、 FnMut も実装し、キャブチャし 
た変数に可変でアクセスする必要のないクロージャは、 Fn も実装しています。リスト 13-12 では、 
equal _ to _ x クロージャは x を不変で借用しています（ゆえに equal _ to _ x は Fn トレイトです)。ク 
ロージャの本体は、 x を読む必要しかないからです。 

環境でクロージャが使用している値の所有権を奪うことをクロージャに強制したいなら、引数リス 
卜の前に move キーワードを使用できます。このテクニックは、新しいスレッドにデータが所有され 
るように、クロージャを新しいスレッドに渡して、データをムーブする際に大概は有用です。 
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並行性について語る第 16 章で、 move クロージャの例はもっと多く出てきます。とりあえず、こち 
らが move キーワードがクロージャ定義に追加され、整数の代わりにベクタを使用するリスト 13-12 
からのコードです。整数はムーブではなく、コピーされてしまいますからね；このコードはまだ コン 
パイルできないことに注意してください。 

フアイル名： src / main.rs 

fn mann() { 

let x = vec! [1, 2, 3]; 

let equal_to_x = move | z| z == x; 

// ここでは、 x を使用できません： {:?} 
pnntin! ("can't use x here: {:?}", x); 

let y = vec! [1, 2, 3]; 


assert! (equal_to_x(y)); 

} 

以下のようなエラーを受けます： 

error[E0382] : use of moved va Lue: x 
(エラー：ムーブ された値の使用： 'x') 

-- > src/mann.rs:6:40 

I 

4 | let equal_to_x = move |z| z == x; 

| - value moved (into closure) here 

( 値はここで（クロー ジヤに）ムーブされた） 

5 | 

6 | println ! ("can' t use x nere : ■{.:?>", x); 

| a value used here after move 

( ムーブ後、値はここで使用された） 

I 

= note : move occurs because 'x' has type 'std :: vec: : Vec<i32>', which does not 
implement the 'Copy' trait 

( 注釈 ： ' x 、 が、 std : : vec : : Vec<i32> 、という ' Copy' トレイトを実装しない型のため、ムー 
ブが起きました） 

クロージャが定義された際に、クロージャに X の値はムーブされています。 move キーワードを追加 
したからです。そして、クロージャは x の所有権を持ち、 main が println! で x を使うことはもう叶 
わないのです。 println! を取り除けば、この例は修正されます。 

Fn トレイトのどれかを指定するほとんどの場合、 Fn から始めると、コンパイラがクロージャ本体 
内で起こっていることにより、 FnMut や FnOnce が必要な場合、教えてくれるでしょう。 

環境をキャブチャできるクロージャが関数の引数として有用な場面を説明するために、次のトピッ 
クに移りましょう：イテレータです。 
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13.2 一連の要素をイテレータで処理する 

イテレータパターンにより、一連の要素に順番に何らかの作業を行うことができます。イテレータ 
は、各要素を繰り返し、シーケンスが終わったことを決定するロジックの責任を負います。イテレー 
夕を使用すると、自身でそのロジックを再実装する必要がなくなるのです。 

Rust において、イテレータは怠惰です。つまり、イテレータを使い込んで消費するメソッドを呼ぶ 
まで何の効果もないということです。例えば、リスト 13-13 のコードは、 Vec < T > に定義された iter 
メソッドを呼ぶことで vl ベクタの要素に対するイテレータを生成しています。このコード単独では、 
何も有用なことはしません。 

let vl = vec ! [1, 2, 3]; 

let vl_nter = vl . iter (); 

リスト 13-13: イテレータを生成する 

一旦イテレータを生成したら、いろんな手段で使用することができます。第3章のリスト 3-5 で 
は、ここまで iter の呼び出しが何をするかごまかしてきましたが、 for ループでイテレータを使い、 
各要素に何かコードを実行しています。 

リスト 13-14 の例は、イテレータの生成と for ループでイテレータを使用することを区別していま 
す。イテレータは、 vl _ iter 変数に保存され、その時には繰り返しは起きていません。 vl _ iter のイテ 
レータで、 for ループが呼び出された時に、イテレータの各要素がループの繰り返しで使用され、各 
値が出力されます。 

let vl = vec ! [1, 2, 3]; 

let vl_nter = vl . iter (); 

for val in vl_iter { 

// {} でした 

println ! (" Got : {}" , val ); 

} 

リスト 13-14： for ループでイテレータを使用する 

標準ライブラリにより提供されるイテレータが存在しない言語では、変数を添え字0から始め、そ 
の変数でベクタに添え字アクセスして値を得て、ベクタの総要素数に到達するまでループでその変数 
の値をインクリメントすることで、この同じ機能を書く可能性が高いでしょう。 

イテ レー タはそのロジック全てを処理してくれるので、めちゃくちゃにしてしまう可能性のある 
コードの 繰り返しを減らしてくれます。イテ レー タにより、添え字を使えるデータ構造、ベクタなど 
だけではなく、多くの異なるシーケンスに対して同じロジックを使う柔軟性も得られます。イテ レー 
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夕がそれをする方法を調査しましょう。 

13.2.1 Iterator トレイトと next メソッド 

全てのイテレータは、標準ライブラリで定義されている Iterator というトレイトを実装していま 
す。このトレイトの定義は、以下のようになっています： 


pub trait Iterator { 
type Item; 


fn next (&mut self) -> Option<Self: :Item>; 

// デフォルト実装のあるメソッドは省略 

// methods with default implementations elided 

} 

この定義は、何か新しい記法を使用していることに気付いてください： type Item と Self: : Item 
で、これらはこのトレイトとの関連型 （associated type) を定義しています。関連型についての詳細 
は、第19章で語ります。とりあえず、知っておく必要があることは、このコードが Iterator トレイ 
卜を実装するには、 Item 型も定義する必要があり、そして、この Item 型が next メソッドの戻り値の 
型に使われていると述べていることです。換言すれば、 Item 型がイテレータから返ってくる型になる 
だろうということです。 

Iterator トレイトは、一つのメソッドを定義することを実装者に要求することだけします： next メ 
ソッドで、これは 1 度に Some に包まれたイテレータの 1 要素を返し、繰り返しが終わったら、 None 
を返します。 

イテレータに対して直接 next メソッドを呼び出すこともできます；リスト 13-15 は、ベクタから生 
成されたイテレータの next を繰り返し呼び出した時にどんな値が返るかを模擬しています。 

ファイル名： src/lib.rs 


# [ test ] 

fn t terator_demonstration () { 
let vl = vec ! [1, 2, 3]; 

let mut vl_iter = vl . iter (); 

assert _ eq ! ( vl _ iter . next (), Some (&1)); 
assert _ eq ! ( vl _ iter . next (), Some (& 2)); 
assert _ eq ! ( vl _ iter . next (), Some (& 3)); 
assert _ eq ! ( vl _ iter . next (), None ) ; 

} 

リスト 13-15: イテレータに対して next メソッドを呼び出す 


vl_iter を可変にする必要があったことに注目してください：イテレータの next メソッドを呼び出 
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すと、今シーケンスのどこにいるかを追いかけるためにイテレータが使用している内部の状態が変わ 
ります。つまり、このコードはイテレータを消費、または使い込むのです。 next の各呼び出しは、イ 
テレータの要素を一つ、食います。 for ループを使用した時には、 vl_iter を可変にする必要はあり 
ませんでした。というのも、ループが vl_iter の所有権を奪い、陰で可変にしていたからです。 

また、 next の呼び出しで得られる値は、ベクタの値への不変な参照であることにも注目してくださ 
い。 iter メソッドは、不変参照へのイテレータを生成します。 vl の所有権を奪い、所有された値を返 
すイテレータを生成したいなら、 iter ではなく into_iter を呼び出すことができます。同様に、可変 
参照を繰り返したいなら、 iter ではなく iter_mut を呼び出せます。 

13.2.2 イテレータを消費するメソッド 

Iterator トレイトには、標準ライブラリが提供してくれているデフォルト実装のある多くの異なる 
メソッドがあります； Iterator トレイトの標準ライブラリの API ドキュメントを検索することで、こ 
れらのメソッドについて知ることができます。これらのメソッドの中には、定義内で next メソッド 
を呼ぶものもあり、故に Iterator トレイトを実装する際には、 next メソッドを実装する必要がある 
のです。 

next を呼び出すメソッドは、消費アダプタ （ consumingadaptors ) と呼ばれます。呼び出しがイ 
テレータの使い込みになるからです。一例は、 sum メソッドで、これはイテレータの所有権を奪い、 
next を繰り返し呼び出すことで要素を繰り返し、故にイテレータを消費するのです。繰り返しが進む 
ごとに、各要素を一時的な合計に追加し、繰り返しが完了したら、その合計を返します。リスト 13-16 
は、 sum の使用を説明したテストです： 

ファイル名： src / lib.rs 


#[ test ] 

fn 1 terator _ sum () { 

let vl = vec ! [1, 2，3]; 

let vl_iter = vl . iter (); 

let total : i 32 = vl _ iter . sum (); 

assert _ eq ! ( total , 6); 

} 

リスト 13-16： sum メソッドを呼び出してイテレータの全要素の合計を得る 

sum は呼び出し対象のイテレータの所有権を奪うので、 sum 呼び出し後に vl _ iter を使用すること 
はできません。 
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13.3 他のイテレータを生成するメソッド 

iterator トレイトに定義された他のメソッドは、イテレータアダプタ (iterator adaptors ) として 
知られていますが、イテ レー タを別の種類のイテ レー タに変えさせてくれます。イテ レー タアダプタ 
を複数回呼ぶ呼び出しを連結して、複雑な動作を読みやすい形で行うことができます。ですが、全て 
のイテ レー タは怠惰なので、消費アダプタメソッドのどれかを呼び出し、イテ レー タアダプタの呼び 
出しから結果を得なければなりません。 

リスト 13-17 は、イテ レー タアダプタメソッドの map の呼び出し例を示し、各要素に対して呼び出 
すクロージャを取り、新しいイテ レー タを生成します。ここのクロージャは、ベクタの各要素が1イ 
ンクリメントされる新しいイテ レー タを作成します。ところが、このコードは警告を発します： 

フアイル名： src / main.rs 
let vl: Vec<i32> = vec! [1, 2, 3]; 
vl.iter().map( | x | x + 1); 

リスト 13-17: イテレータアダプタの map を呼び出して新規イテレータを作成する 

出る警告は以下の通りです： 

warning: unused std :: iter :: Map which must be used : iterator adaotors are lazv 
and do nothing unless consumed 

(警告：使用されねばならない' std:: iter ■:: Map' が未使用です：イテレータアダプタは怠 
惰で、 

消費されるまで何もしません） 

-- > src/mann.rs :4:5 

I 

4 | vl.iter().map(| x | x + 1); 

| 八八八八八八八八八八八八八八八八八八八八八八八八八 

I 

=note : #[warn(unused_must_use)] on by default 

リスト 13-17 のコードは何もしません；指定したクロージャは、決して呼ばれないのです。警告が 
理由を思い出させてくれています：イテレータアダプタは怠惰で、ここでイテレータを消費する必要 
があるのです。 

これを修正し、イテレータを消費するには、 collect メソッドを使用しますが、これは第 12 章の 
リスト 12-1 で env :: args とともに使用しました。このメソッドはイテレータを消費し、結果の値を 
コレクション データ型に集結させます。 

リスト 13-18 において、 map 呼び出しから返ってきたイテレータを繰り返した結果をベクタに集結 
させています。このべクタは、最終的に元のベクタの各要素に1を足したものが含まれます。 
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フアイル名： src / mam.rs 
let vl: Vec<i32> = vec! [1, 2, 3]; 

let v2 : Vec<_> = vl.iter().map(|x| x + 1).collect(); 
assert_eq! (v2, vec! [2, 3 ， 4]); 

リスト 13-18: map メソッドを呼び出して新規イテ レー タを作成し、それから collect メソッドを 
呼び出してその新規イテ レー タを消費し、ベクタを生成する 

map はクロージャを取るので、各要素に対して行いたいどんな処理も指定することができます。こ 
れは、 Iterator トレイトが提供する繰り返し動作を再利用しつつ、クロージャにより一部の動作を力 
スタマイズできる好例になっています。 

13.3.1 環境をキャブチャするクロージャを使用する 

イテ レー タが出てきたので、 filter イテ レー タアダプタを使って環境をキャブチャするクロージャ 
の一般的な使用をデモすることができます。イテ レー タの filter メソッドは、イテ レー タの各要素 
を取り、論理値を返すクロージャを取ります。このクロージャが true を返せば、 filter が生成する 
イテ レー タにその値が含まれます。クロージャが false を返したら、結果のイテ レー タにその値は含 
まれません。 

リスト 13-19 では、環境から shoe_size 変数をキャプチャする クロー ジャで filter を使って、 
Shoe 構造体 イ ン スタンスのコレク シヨンを繰り返しています。指定した サイズの 靴だけを返すわけ 
です。 

ファイル名： src / lib.rs 

# [derive(PartialEq ， Debug)j 
struct Shoe { 
size: u32 , 
style : String, 

} 

fn shoes_in_my_size(shoes : Vec<Shoe>, shoe_size : u32) -> Vec<Shoe> { 
shoes.into_iter() 

.filter(|s| s. size == shoe_size) 

.collect() 

} 

#[test] 

fn fiIters_by_size() { 
let shoes = vec! [ 

Shoe { size: 10 ， style : String: : f rom("sneaker") }， 

Shoe { size: 13 ， style : String: : f rom("sandal ") }， 

Shoe { size: 10 ， style : String: : f rom("boot") }， 



第 13 章関数型言語の機能：イテレータとクロージャ 


302 


]； 


let in _ my_size = snoes _ in _ my _ size ( shoes , 10); 

assert _ eq ! ( 

in _ my _ size , 
vec ! [ 

Shoe { size :10， style : String : : from (" sneaker ") }， 

Shoe { size :10， style : String : : from (" boot ") }， 

] 

)； 

> 

リスト 13-19: shoe_si ze をキャプチャするクロー ジャで fi Iter メソッドを使用する 

shoes _ in _ my _ size 関数は、引数として靴のベクタとサイズの所有権を奪います。指定されたサイズ 
の靴だけを含むベクタを返します。 

shoes _ in _ my _ size の本体で、 into _ iter を呼び出してベクタの所有権を奪うイテ レー タを作成し 
ています。そして、 filter を呼び出してそのイテ レー タをクロージャが true を返した要素だけを含 
む新しいイテ レー タに適合させます。 

クロージャは、環境から sh 0 e _ S i Z e 引数をキャブチャし、指定されたサイズの靴だけを保持しなが 
ら、その値を各靴のサイズと比較します。最後に、 collect を呼び出すと、関数により返ってきたべ 
クタに適合させたイテレータから返ってきた値が集まるのです。 

shoes _ in _ my _ size を呼び出した時に、指定した値と同じサイズの靴だけが得られることをテスト 
は示しています。 

13.3.2 Iterator トレイトで独自のイテレータを作成する 

ベクタに対し、 iter 、 into _ iter 、 iter _ mut を呼び出すことでイテレータを作成できることを示 
してきました。ハッシュマップなどの標準ライブラリの他のコレクション型からもイテレータを作成 
できます。 Iterator トレイトを自分で実装することで、したいことを何でもするイテレータを作成す 
ることもできます。前述の通り、定義を提供する必要のある唯一のメソッドは 、 next メソッドなので 
す。一旦、そうしてしまえば、 Iterator トレイトが用意しているデフォルト実装のある他の全てのメ 
ソッドを使うことができるのです！ 

デモ用に、絶対に1から5をカウントするだけのイテレータを作成しましょう。まず、値を保持す 
る構造体を生成し、 Iterator トレイトを実装することでこの構造体をイテレータにし、その実装内の 
値を使用します。 

リスト 13-20 は、 Counter 構造体と Counter のインスタンスを作る new 関連関数の定義です： 

ファイル名： src / lib.rs 


struct Counter { 
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count : uj2 , 

} 

impL Counter { 

fn new() -> Counter i 
Counter { count : 0 } 



リスト 13-20: Counter 構造体と count に対して0という初期値で Counter のインスタンスを作る 
new 関数を定義する 

Counter ■構造体には、 count というフィールドがあります。このフィールドは、1から5までの繰 
り返しのどこにいるかを追いかける u 32 値を保持しています。 Counter ■の実装にその値を管理してほ 
しいので、 count フィールドは非公開です。 count フィールドは常に0という値から新規インスタン 
スを開始するという動作を new 関数は強要します。 

次に、 next メソッドの本体をこのイテレータが使用された際に起きてほしいことを指定するように 
定義して、 Counter ■型に対して Iterator トレイトを実装します。リスト 13-21 のようにですね： 

ファイル名： src / lib.rs 

# struct Counter { 

# count : u 32 , 

# } 

# 

impl Iterator for Counter { 
type Item = u 32 ; 

fn next (&mut self ) -> OptiorKSelf :: Item > { 
self .count +=1; 

if self .count < 6 { 

Some ( self . count ) 

} else { 

None 



リスト 13-21: Counter 構造体に Iterator トレイトを実装する 

イテ レー タの Item 関連型を u32 に設定しました。つまり、イテ レー タは、 U 32 の値を返します。こ 
こでも、まだ関連型について心配しないでください。第19章で講義します。 

イテ レー タに現在の状態に 1 を足してほしいので、まず 1 を返すように count を 0 に初期化しま 
した。 count の値が5以下なら、 next は Some に包まれた現在の値を返しますが、 count が6以上な 
ら、イテ レー タは None を返します。 
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13.3 .2.1 Counter イテレータの next メソッドを使用する 
一旦 Iterator トレイトを実装し終わったら、イテレータの出来上がりです！リスト 13-22 は、リ 
スト 13-15 のべクタから生成したイテレータと全く同様に、直接 next メソッドを呼び出すことで、 
Counter 構造体のイテレータ機能を使用できることをデモするテストを示しています。 

ファイル名： src / lib.rs 

# struct Counter { 

# count : u 32 , 

# } 

# 

# impl Iterator for Counter { 

# type Item = u 32 ; 

# 

# fn next (&mut self ) -> OptiorKSelf :: Item > { 

# 

# 

# 

# 

# 

# 

# 

# } 

# } 

# 

#[ test ] 

fn calling _ next _ directly () { 

let mut counter = Counter :: new (); 

assert _ eq ! ( counter . next (), Some ( l ) ); 
assert _ eq ! ( counter . next (), Some (2) ); 
assert _ eq ! ( counter . next (), Some (3) ); 
assert _ eq ! ( counter . next (), Some (4)); 
assert _ eq ! ( counter . next (), Some (5) ); 
assert _ eq ! ( counter . next (), None ) ; 

} 

リスト 13-22： next メソッド実装の機能をテストする 

このテストは、 counter 変数に新しい Counter ■インスタンスを生成し、それからイテレ^ータにほし 
い動作が実装し終わっていることを実証しながら、 next を繰り返し呼び出しています：1から5の値 
を返すことです。 

13.3.2.2 他の Iterator トレイトメソッドを使用する 
next メソッドを定義して Iterator トレイトを実装したので、今では、標準ライブラリで定義され 
ているように、どんな Iterator トレイトメソッドのデフオルト実装も使えるようになりました。全 


self .count +=1; 

it self .count < 6 { 
Some ( self . count ) 
} else { 

None 

} 
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て next メソッドの機能を使っているからです。 

例えば、何らかの理由で、 Counter インスタンスが生成する値を取り、最初の値を飛ばしてから、 
別の Counter インスタンスが生成する値と一組にし、各ペアを掛け算し、3で割り切れる結果だけを 
残し、全結果の値を足し合わせたくなったら、リスト 13-23 のテストに示したように、そうすること 
ができます： 

ファイル名： src / lib.rs 

# struct Counter { 

# count : u 32, 

# } 

# 

# impl Counter { 

# fn new () -> Counter { 

# Counter { count : 0 } 

# } 

# } 

# 

# impl Iterator for Counter { 

# // このイテレータは u 32 を生成します 

# // Our iterator will produce u 32 s 

# type Item = u 32 ; 

# 

# 

# 

# 

# 

# 

# // カウントが終わったかどうか確認する 

# // check to see if we've finished counting or not . 

# if self .count < 6 { 

# Some ( self . count ) 

# } else { 

# None 

# } 

# } 

# } 

# 

#[ test ] 

fn usi ng _ other _ iterator _ trait _ methods () { 

let sum : u 32 = Counter : : new (). zip ( Counter : : new (). skip ( l )) 

• map (|( a , b )| a * b ) 

. filter (| x | x % 3 == 0) 

. sum (); 

assert _ eq ! (18, sum ); 

} 

リスト 13-23: Counter イテレータに対していろんな Iterator トレイトのメソッドを使用する 
zip は4組しか生成しないことに注意してください；理論的な5番目の組の（5， None ) は、入カイ 


fn next (&mut self ) -> OptiorKSelf : : Item > { 

// カウントをインクリメントする。故に0から始まる 
// increment our count . This is why we started at zero , 
self .count +=1; 
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テレータのどちらかが None を返したら、 zip は None を返却するため、決して生成されることはあり 
ません。 

next メソッドの動作方法を指定し、標準ライブラリが next を呼び出す他のメソッドにデフォルト 
実装を提供しているので、これらのメソッド呼び出しは全て可能です。 

13.4 入出カプロジェクトを改善する 

このイテレータに関する新しい知識があれば、イテレータを使用してコードのいろんな場所をより 
明確で簡潔にすることで、第12章の入出カプロジヱタトを改善することができます。イテレータが 
Config : : new 関数と search 関数の実装を改善する方法に目を向けましょう。 

13.4.1 イテレータを使用して clone を取り除く 

リスト 12-6 において、スライスに添え字アクセスして値をクローンすることで、 Config 構造体に 
値を所有させながら、 String 値のスライスを取り、 Config 構造体のインスタンスを作るコードを追 
記しました。リスト 13-24 では、リスト 12-23 のような Config : : new の実装を再現しました： 

ファイル名： src / lib.rs 

impl Config i 

pub fn new ( args : & [ String ] ) -> Result < Confi g ， static str > { 
if args . len () < 3 { 

return Err ("not enough arguments ") ; 

} 

let query = args [1]. clone (); 
let tiL ename = args [2]. clone (); 

let case_sensitive = env : : var (" CASE _ INSENSITIVE ") . is _ err (); 

Ok (Config { query , ti tename , case_sensitive }) 

} 

} 

リスト 13-24: リスト 12-23 から Config : : new 関数の再現 

その際、将来的に除去する予定なので、非効率的な clone 呼び出しを憂慮するなと述べました。 
えっと、その時は今です！ 

引数 args に String 要素のスライスがあるためにここで clone が必要だったのですが、 new 関数は 
args を所有していません。 Config インスタンスの所有権を返すためには、 Config インスタンスがそ 
の値を所有できるように、 Config の query と filename フィ ー ルドから値を クロー ンしなければなり 
ませんでした。 

イテ レー タに ついての 新しい知識があれば、 new 関数をスライスを借用する代わりに、引数と して 
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イテ レー タの所有権を奪うように変更することができます。スライスの長さを確認し、特定の場所に 
添え字アクセスするコードの代わりにイテ レー タの機能を使います。これにより、イテ レー タは値に 
アクセスするので、 Config : : new 関数がすることが明確化します。 

ひとたび、 Config : :new がイテレータの所有権を奪い、借用する添え字アクセス処理をやめたら、 
clone を呼び出して新しく メモリ確保するのではなく、イテレータからの String 値を Config にムー 
ブできます。 


13.4.1.1 返却されるイテレータを直接使う 

入出カプロジヱクトの src/main.rs フアイルを開いてください。こんな見た目のはずです: 
フアイル名： src / main.rs 
fn mann () { 

let args : Vec < String > = env : : args (). collect (); 

let config = Coring : : new (& args ). unwrap _ or _ else ( | err | { 
eprintln! ("Problem parsing arguments : {}" , err ); 
process :: exit ( l ) ; 

})； 


// __ snip __ 

} 


リスト 12-24 のような main 関数の冒頭をリスト 13-25 のコードに変更します。これは、 Config :: 
new も更新するまでコンパイルできません 0 


フアイル名： src / main.rs 
rn main () { 

let config = Confng : : new ( env : : args ()). unwrap _ or _ else (| err | { 
eprintln! ("Problem parsing arguments : {}" , err ); 
process :: exit ( l ) ; 

})； 


// -- snip __ 

} 

リスト 13-25: env : : args の民り値を Config : : new に渡す 

env :: args 関数は、イテレータを返します！イテレータの値をベクタに集結させ、それからスライ 
スを Config : : new に渡すのではなく、今では env : : args から返ってくるイテレータの所有権を直接 
Config : : new に渡しています。 

次に、 Config : :new の定義を更新する必要があります。入出カプロジェクトの Src/lib.rS ファイル 
で、 Configxnew のシグニチヤをリスト 13-26 のように変えましょう。関数本体を更新する必要があ 
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るので、それでもコンパイルはできません。 

ファイル名： src / lib.rs 

impl Config i 

pub fn new(mut args : std :: env : : Args ) -> Result < Confi g , &' static str > { 

// --snip 

リスト 13-26: Config : : new のシグニチャをイテレータを期待するように更新する 

env : : args 関数の標準ライブラリドキュメントは、自身が返すイテレータの型は、 std : : env : : Args 
であると表示しています。 Config : :new 関数のシグニチャを更新したので、引数 args の型は、 &[ 
String ] ではなく、 std : : env : : Args になりました。 args の所有権を奪い、繰り返しを行うことで args 
を可変化する予定なので、 args 引数の仕様に mut キーワードを追記でき、可変にします。 

13.4.1.2 添え字の代わりに Iterator トレイトのメソッドを使用する 
次に、 Config : :new の本体を修正しましよう。標準ライブラリのドキュメントは、 std : : env : : Args 
が Iterator トレイトを実装していることにも言及しているので、それに対して next メソッドを呼び 
出せることがわかります！リスト 13-27 は、リスト 12-23 のコードを next メソッドを使用するよ 
うに更新したものです： 

ファイル名： src / lib.rs 

# fn main () {} 

# use std :: env ; 

# 

# struct Conng { 

# query : String , 

# filename : String , 

# case _ sensitive : bool , 

# } 

# 

impl Config { 

pub fn new(mut args : std :: env :: Args ) -> Result < Config , &' static str > { 
args • next (); 

let query = match args . next () { 

Some ( arg ) => arg , 

// ク エリ 文字列を取得しませんでした 

None => return Err (" Didn't get a query string 11 ), 

}； 

let ti lename = match args . next () { 

Some ( arg ) => arg , 

// ファイル名を取得しませんでした 

None => return Err (" Didn't get a file name ") , 


}； 
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let case_sensitive = env : : var (" CASE _ INSENSITIVE ") . is _ err (); 

Ok(Config { query , ti Lename , case_sensitive }) 

} 

} 

リスト 13-27： Config :: new の本体をイテレータメソッドを使うように変更する 

env :: args の戻り値の1番目の値は、プログラム名であることを思い出してください。それは無視 
し、次の値を取得したいので、まず next を呼び出し、戻り値に対して何もしません。2番目に 、 next 
を呼び出して Config の query フイールドに置きたい値を得ます。 next が Some を返したら、 match を 
使用してその値を抜き出します。 None を返したら、十分な引数が与えられなかったということなの 
で、 Err 値で早期リターンします。 fUename 値に対しても同じことをします。 

13.4.2 イテレータアダプタでコードをより明確にする 

入出カプロジェクトの search 関数でも、イテレータを活用することができ、その関数は、リスト 
12-19 のように、ここリスト 13-28 に再現しました。 

ファイル名： src / lib.rs 

pub rn search <' a >( query : & str , contents : &'a str ) -> Vec<&' a str > { 
let mut results = Vec :: new (); 

for line in contents • lines () { 
if line • contains ( query ) { 
results . push ( line ); 

} 

} 


results 

} 

リスト 13-28: リスト 12-19 の search 関数の実装 

イテレータアダプタメソッドを使用して、このコードをもっと簡潔に書くことができます。そうす 
れば、可変な中間の results ベクタをなくすこともできます。関数型プログラミングスタイルは、可 
変な状態の量を最小化することを好み、コードを明瞭化します。可変な状態を除去すると、検索を同 
時並行に行うという将来的な改善をするのが、可能になる可能性があります。なぜなら、 results べク 
夕への同時アクセスを管理する必要がなくなるからです。リスト 13-29 は、この変更を示しています: 

ファイル名： src / lib.rs 

pub rn search <' a >( query : & str , contents : &'a str ) -> Vec<&' a str > { 
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contents . Lines () 

.f 1 Iter * (| li ne | li ne . contai ns ( query ;) 

. collect () 

} 

リスト 13-29: search 関数の実装でイテレータアダプタのメソッドを使用する 

search 関数の目的は、 query を含む contents の行全てを返すことであることを思い出してくださ 
い。リスト 13-19 の filter 例に酷似して、このコードは filter アダプタを使用して line.contains 
(query) が真を返す行だけを残すことができます。それから、合致した行を別のベクタに collect で 
集結させます0ずっと単純です！ご自由に、同じ変更を行い、 search_case_insensitive 関数でもイ 
テレータメソッドを使うようにしてください。 

次の論理的な疑問は、自身のコードでどちらのスタイルを選ぶかと理由です：リスト 13-28 の元の 
実装とリスト 13-29 のイテレータを使用するバージョンです。多くの Rust プログラマは、イテレー 
タスタイルを好みます。とっかかりが少し困難ですが、いろんなイテレータアダプタとそれがするこ 
との感覚を一度掴めれば、イテレータの方が理解しやすいこともあります。いろんなループを少しず 
つもてあそんだり、新しいベクタを構築する代わりに、コードは、ループの高難度の目的に集中でき 
るのです。これは、ありふれたコードの一部を抽象化するので、イテレータの各要素が通過しなけれ 
ばならないふるい条件など、このコードに独特の概念を理解しやすくなります。 

ですが、本当に2つの実装は等価なのでしょうか？直観的な仮説は、より低レベルのループの方 
がより高速ということかもしれません。パフォーマンスに触れましょう。 

13.5 パフォーマンス比較：ループ VS イテレータ 

ループを使うべきかイテ レー タを使うべきか決定するために、 search 関数のうち、どちらのバー 
ジョンが速いか知る必要があります：明示的な for ループがあるバージョンと、イテ レー タのバー 
ジョンです。 

サー.アーサー.コナン.ドイル （Sir Arthur Conan Doyle) の、シャーロックホームズの冒険 
(The Adventures of Sherlock Homes) 全体を string に読み込み、そのコンテンツで the という 
単語を検索することでベンチマークを行いました。こちらが、 for を使用した search 関数のバージョ 
ンと、イテレータを使用したバージョンに関するベンチマーク結果です。 

test bench _ search_for ... bench : 19,620，300 ns/iter (+/- 915,700) 
test bench _ search_iter ... bench : 19,234,900 ns/iter (+/- 657,200) 

イテレータパージョンの方が些（いささ）か高速ですね！ここでは、ベンチマークのコードは説明 
しません。なぜなら、要点は、2つのバージョンが等価であることを証明することではなく、これら 
2つの実装がパフォーマンス的にどう比較されるかを大まかに把握することだからです。 

より理解しやすいベンチマークには、いろんなサイズの様々なテキストを contents として、異な 
る単語、異なる長さの単語を query として、他のあらゆる種類のバリエーションを確認するべきです。 
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重要なのは：イテレータは、高度な抽象化にも関わらず、低レベルのコードを自身で書いているかの 
ように、ほぼ同じコードにコンパイルされることです。イテレータは、 Rust のゼロ代償抽象化の一つ 
であり、これは、抽象化を使うことが追加の実行時オーバーへッドを生まないことを意味しています。 
このことは、 C ++ の元の設計者であり実装者のビヤーネ•ストロヴストルップ （Bjarne Stroustrup ) 
が、ゼロオーパーヘッドを 「 C ++ の基礎（2012)」で定義したのと類似しています。 

一般的に、 C ++ の実装は、ゼロオーバーヘッド原則を遵守します：使用しないものには、支払 
わなくてよい。さらに：実際に使っているものに対して、コードをそれ以上うまく渡すことは 
できない。 

別の例として、以下のコードは、オーディオデコーダから取ってきました。デコードアルゴリズム 
は、線形予測数学演算を使用して、以前のサンプルの線形関数に基づいて未来の値を予測します。こ 
のコードは、イテレータ連結をしてスコープにある3 つの 変数に計算を行っています： buffer という 
データのスライス、12の coefficients (係数）の配列、 qlp _ shift でデータをシフトする量です。こ 
の例の中で変数を宣言しましたが、値は与えていません；このコードは、文脈の外では大して意味を 
持ちませんが、それでも Rust が高レベルな考えを低レベルなコードに翻訳する簡潔で現実的な例に 
なっています： 

let buffer : &mut [i 32] ; 

Let coetncients: [i64; 12 」； 

let qlp_shift : i 16; 

for i in 12..buffer.len() { 

let prediction = coefficients.i.ter() 

.zip(&buffer[i - 12..i]) 

.map(|(&c, &s)| c * s as i 64) 

.sum: : <i64> () >> qlp_shift; 

let delta = buffer[i]; 

buffer い 」 =prediction as i32 + delta; 

} 

prediction の値を算出するために、このコードは、 coefficients の12の値を繰り返し 、 zip メ 
ソッドを使用して、係数値を前の buffer の12の値と組にします。それから各組に ついて、 その値を 
かけ合わせ、結果を全て合計し、合計のビットを qlp _ shi _ ft ビット分だけ右にシフトさせます。 

オーディオデコーダのようなアプリケーシヨンの計算は、しばしばパフォーマンスに最も重きを置 
きます。ここでは、イテレータを作成し、2つのアダプタを使用し、それから値を消費しています。 
この Rust コードは、どんな機械語コードにコンパイルされるのでしょうか？え一、執筆時点では、 
手作業で書いたものと同じ機械語にコンパイルされます 。 coeffi dents の値の繰り返しに対応する 
ループは全く存在しません：コンパイラは、12回繰り返しがあることを把握しているので、ループを 
「展開」します。ループの展開は、ループ制御コードのオーバーヘッドを除去し、代わりにループの繰 
り返しごとに同じコードを生成する最適化です。 

係数は全てレジスタに保存されます。つまり、値に非常に高速にアクセスします。実行時に配列の 
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境界チェックをすることもありません。コンパイラが適用可能なこれらの最適化全てにより、結果の 
コードは究極的に効率化されます。このことがわかったので、もうイテレータとクロージャを恐れな 
しに使用することができますね！それらのおかげでコードは、高レベルだけれども、そうすることに 
対して実行時のパフォーマンスを犠牲にしないようになります。 

13.6 まとめ 

クロージャとイテレータは、関数型言語の考えに着想を得た Rust の機能です。低レベルのパフォー 
マンスで、高レベルの考えを明確に表現するという Rust の能力に貢献しています。クロージャとイ 
テレータの実装は、実行時のパフォーマンスが影響されないようなものです。これは、ゼロ代償抽象 
化を提供するのに努力を惜しまない Rust の目標の一部です。 

今や人出カプロジヱクトの表現力を改善したので、プロジヱクトを世界と共有するのに役に立つ 
cargo の機能にもっと目を向けましょう。 
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14； 


Cargo と Crates.io についてより詳しく 


今まで Cargo のビルド、実行、コードのテストを行うという最も基礎的な機能のみを使ってきまし 
たが、他にもできることはたくさんあります。この章では、そのような他のより高度な機能の一部を 
議論し、以下のことをする方法をお見せしましょう： 

•リリースプロファイルでビルドをカスタマイズする 

• crates.io でライブラリを公開する 

• ワーク スペースで 巨大なプロジェクトを体系化する 

• crates.io からバイナリをインストールする 

• 独自のコマンドを使用して Cargo を拡張する 


また、 Cargo はこの章で講義する以上のこともできるので、機能の全解説を見るには、ドキュメン 
テーションを 参照されたし。 

14.1 リリースプロファイルでビルドをカスタマイズする 

Rust において、リリースプロファイルとは、プログラマがコードのコンパイルオプションについて 
より制御可能にしてくれる、定義済みのカスタマイズ可能なプロファイルです。各プロファイルは、 
それぞれ独立して設定されます。 

Cargo には 2つの 主なプロファイルが存在します： dev プロファイルは 、 cargo build コマンドを 
実行したときに使用され、 release プロファイルは 、 cargo build -- release コマンドを実行したと 
きに使用されます。 dev プロファイルは、開発中に役に立つデフォルト設定がなされており 、 release 
プロファイルは、リリース用の設定がなされています。 

これらのプロファイル名は、ビルドの出力で馴染みのある可能性があります： 

$ cargo build 

Finished dev [unoptimized + debuginfo 」 target ( s)in 0.0 secs 



第 14 章 Cargo と Crates.io についてより詳しく 


314 


$ cargo buiLd --re Lease 

Finished release [ optimized ] target ( s)in 0.0 secs 


このビルド出力で表示されている dev と release は、コンパイラが異なるプロファイルを使用して 
いることを示しています。 

プロジェクトの Cargo.toml ファイルに [ profile .*] セクションが存在しない際に適用される各 
プロファイル用のデフォルト設定が、 Cargo には存在します。カスタマイズしたいプロファイル用の 
[ profile .*] セクションを追加することで、デフォルト設定の一部を上書きすることができます。例 
えば、こちらが dev と release プロファイルの opt - levet 設定のデフオルト値です： 

ファイル名： Cargo.toml 

[ profile . dev ] 
opt - level =0 


[prori ie . release ] 
opt - level = 3 

opt - level 設定は、 0 から 3 の範囲でコンパイラがコードに適用する最適化の度合いを制御します。 
最適化を多くかけると、コンパイル時間が延びるので、開発中に頻繁にコードをコンパイルするのな 
ら、たとえ出力結果のコードの動作速度が遅くなっても早くコンパイルが済んでほしいですよね。こ 
れが、 dev の opt - level のデフオルト設定が0になっている唯一の理由です。コードのリリース準備 
ができたら、より長い時間をコンパイルにかけるのが最善の策です。リリースモードでコンパイル 
するのはたった1回ですが、コンパイル結果のプログラムは何度も実行するので、リリースモード 
では、長いコンパイル時間と引き換えに、生成したコードが速く動作します。そのため、 release の 
opt - level のデフオルト設定が3になっているのです。 

デフォルト設定に対して Cargo . toml で異なる値を追加すれば、上書きすることができます。例 
として、開発用プロファイルで最適化レベル1を使用したければ、以下の2行をプロジェクトの 
Cargo.toml ファイルに追加できます： 

ファイル名： Cargo.toml 

[ proriie . dev 」 
opt - level =1 

このコードは、デフォルト設定の 0 を上書きします。こうすると 、 cargo build を実行したときに、 
dev プロファイル用のデフォルト設定に加えて、 Cargo は opt - level の変更を適用します。 opt-level 
を 1 に設定したので、 Cargo はデフォルトよりは最適化を行いますが、リリースビルドほどではあり 
ません。 

設定の選択肢と各プロファイルのデフォルト設定の一覧は、 Cargo のドキュメンテーションを参照 
されたし。 
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14.2 Crates . io にクレートを公開する 

プロジェクトの依存として crates.io のパッケージを使用しましたが、自分のパッケージを公開す 
ることで他の人とコードを共有することもできます。 crates.io のクレート登録所は、自分のパッケー 
ジの ソースコー ドを配布するので、主にオープン ソースのコー ドを ホスト します。 

Rust と Cargo は、公開したパッケージを人が使用し、そもそも見つけやすくしてくれる機能を有 
しています。これらの機能の一部を次に語り、そして、パッケージの公開方法を説明します。 

14.2.1 役に立つドキュメンテーションコメントを行う 

パッケージを正確にドキュメントすることで、他のユーザがパッケージを使用する方法や、いつ使 
用すべきかを理解する手助けをすることになるので、ドキュメンテーションを書くことに時間を費や 
す価値があります。第 3 章で、 2 連スラッシュ、//で Rust のコードにコメントをつける方法を議論 
しました。 Rust には、ドキュメンテーション用のコメントも用意されていて、便利なことにドキュメ 
ンテー ショ ンコメントとして知られ、 HTML ドキュメントを生成します。クレートの実装法とは対照 
的にクレートの使用法を知ることに興味のあるプログラマ向けの、公開 API 用のドキュメンテーショ 
ンコメントの中身をこの HTML は表示します。 

ドキュメンテーションコメントは、2つではなく、3連スラッシュ、///を使用し、テキストを整形 
する Markdown 記法もサポートしています。ドキュメント対象の要素の直前にドキュメンテーショ 
ンコメントを配置してください。リスト 14-1 は 、 my _c rate という名のクレートの add _ one 関数用の 
ドキュメンテーションコメントを示しています： 

ファイル名： src / lib.rs 


III Adds one to the number given . 

Ill 与えられた数値に 1 を足す。 

III 

III # Examples 

III 

///'、、 

III let five = 5; 

III 

III assert _ eq !(6, my _ crate :: add _ one (5)); 
///、、、 

pub fn add _ one ( x : i 32) -> i 32 { 
x + 1 

} 


リスト 14-1: 関数のドキュメンテーションコメント 


ここで、 add _ one 関数がすることの説明を与え、 Examples というタイトルでセクションを開始し、 
add _ one 関数の使用法を模擬するコードを提供しています。このドキュメンテーションコメントか 
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ら cargo doc を実行することで、 HTML ドキュメントを生成することができます。このコマンドは 
コンパイラとともに配布されている rustdoc ツールを実行し、生成された HTML ドキュメントを 
target / doc ディレクトリに配置します。 

利便性のために、 cargo doc --open を走らせれば、現在のクレートのドキュメント用の HTML (と、 
自分のクレートが依存している全てのドキュメント）を構築し、その結果を Web ブラウザで開きま 
す。 add_ 0ne 関数まで下り、図 14-1 に示したように、ドキュメンテーションコメントのテキストがど 
う描画されるかを確認しましょう： 

_ Click or press ‘S’ to search〆？’ for more options... 

my_crate 


Functions 


Function my_crate::add_one 


[-][src] 


add_one 


Crates 

my_crate 


pub fn add_one(x: i32) -> i^2 


Adds one to the number given. 

Examples 


let five = 5; 

assert_eq! (6, my 一 crate::add 一 one(5)); 


図 14-1: add_one 関数の HTML ドキュメント 

14.2.1.1 よく使われるセクション 

# Examples マークダウンのタイトルをリスト 14-1 で使用し、「例」というタイトルのセクションを 
HTML に生成しました。こちらがこれ以外にドキュメントでよくクレート筆者が使用するセクショ 
ンです： 

• Panics ： ドキュメント対象の関数が panic! する可能性のある筋書きです。プログラムをパ 
ニックさせたくない関数の使用者は、これらの状況で関数が呼ばれないことを確かめる必要が 
あります。 

• Errors ： 関数が Result を返すなら、起きうるエラーの種類とどんな条件がそれらのエラーを 
弓 I き起こす可能性があるのか解説すると、呼び出し側の役に立つので、エラーの種類によって 
処理するコードを変えて書くことができます。 
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• Safety : 関数が呼び出すのに unsafe ( unsafe については第19章で議論します）なら、関数が 
unsafe な理由を説明し、関数が呼び出し元に保持していると期待する不変条件を講義するセ 
クションがあるべきです。 

多くのドキュメンテーションコメントでは、これら全てのセクションが必要になることはありませ 
んが、これは自分のコードを呼び出している人が知りたいと思うコードの方向性を思い出させてくれ 
るいいチヱックリストになります。 

14.2 .1.2 テストとしてのドキュメンテーションコメント 

ドキュメンテーションコメントに例のコードブロックを追加すると、ライブラリの使用方法のデモ 
に役立ち、おまけもついてきます： cargo test を走らせると、ドキュメントのコード例をテストとし 
て実行するのです！例付きのドキュメントに上回るものはありません。しかし、ドキュメントが書か 
れてからコードが変更されたがために、動かない例がついているよりも悪いものもありません。リス 
卜 14-1 から add_one 関数のドキュメンテーションとともに、 cargo test を走らせたら、テスト結果 
に以下のような区域が見られます： 

Doc-tests my_crate 

running 1 test 

test src/lib. rs - add_one (line 5) "• ok 

test result : ok.1 passed; 0 failed; 0 ignored; 0 measured; 0 Tittered out 

さて、例の asser*t_eq ! がパニックするように、関数か例を変更し、再度 cargo test を実行したら、 
doc テストが、例とコードがお互いに同期されていないことを捕捉するところを目撃するでしょう！ 

14.2 .1.3 含まれている要素にコメントする 

doc コメントの別スタイル、//!は、コメントに続く要素にドキュメンテーションを付け加えるの 
ではなく、コメントを含む要素にドキュメンテーションを付け加えます。典型的には、クレートの 
ルートファイル（規定では、 src / lib . rs ) 内部や、モジュールの内部で使用して、クレートやモジュー 
ル全体にドキュメントをつけます。 

例えば、 add_one 関数を含む my_crate クレートの目的を解説するドキュメンテーションを追加し 
たいのなら、//!で始まるドキュメンテーションコメントを src / lib.rs ファイルの先頭につけること 
ができます。リスト 14-2 に示したようにですね： 

ファイル名： src / lib.rs 


//! # My Crate 
//! 

//! my_crate is a collection or utilities to make performing certain 
//! calculations more convenient. 
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III Adds one to the number given. 

// -- snip -- 

リスト 14-2: 全体として my _ crate クレートにドキュメントをつける 

//!で始まる最後の行以降には、コードが何もないことに気付いてください。///ではなく、//!で 
コメントを開始しているので、このコメントに続く要素ではなく、このコメントを含む要素にドキュ 
メントをつけているわけです。今回の場合、このコメントを含む要素は src/lib.rs ファイルであり、 
クレートのルートです。これらのコメントは、クレート全体を解説しています。 

cargo doc -- open を実行すると、これらのコメントは、 my _ crate のドキュメントの最初のぺージ、 
クレートの公開要素のリストの上部に表示されます。図 14-2 のようにですね： 

Click or press ‘S’ to search, l T for more options... 


Crate my_crate [-] [src] 

卜} My Crate 

my_c rate is a collection of utilities to make performing certain calculations 
more convenient. 

Functions 

add 一 one Adds one to the number given. 

図 14-2: クレート全体を解説するコメントを含む my _ crate の描画されたドキュメンテーシヨン 

要素内のドキュメンテーシヨンコメントは、特にクレートやモジュールを解説するのに有用です。 
コンテナの全体の目的を説明し、クレートの使用者がクレートの体系を理解する手助けをするのに使 
用してください。 

14.2.2 pub use で便利な公開 API をエクスポートする 

第7章において、 mod キーワードを使用してモジュールにコードを体系化する方法、 pub キーワー 
ドで要素を公開にする方法、 use キーワードで要素をスコープに導入する方法について講義しまし 
た。しかしながら、クレートの開発中に、自分にとって意味のある構造は、ユーザにはあまり便利で 
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はない可能性があります。複数階層を含む階層で、自分の構造体を体系化したくなるかもしれませ 
んが、それから階層の深いところで定義した型を使用したい人は、型が存在することを見つけ出す 
のに困難を伴う可能性もあります。また、そのような人は 、 use my_crate: :UsefulType の代わりに 
use my_crate : : some_modu1e : : anothe 「 _modu1e: : UsefulType ;と入力するのを煩わしく 感じる可能性 
もあります。 

自分の公開 API の構造は、クレートを公開する際に考慮すべき点です。自分のクレートを使用した 
い人は、自分よりもその構造に馴染みがないですし、クレートのモジュール階層が大きければ、使用 
したい部分を見つけるのが困難になる可能性があります。 

嬉しいお知らせは、構造が他人が他のライブラリから使用するのに便利ではない場合、内部的な体 
系を再構築する必要はないということです：代わりに、要素を再エクスポートし 、 pub use で自分の 
非公開構造とは異なる公開構造にできます。再エクスポートは、ある場所の公開要素を一つ取り、別 
の場所で定義されているかのように別の場所で公開します。 

例えば、芸術的な概念をモデル化するために art という名のライブラリを作ったとしましょう。こ 
のライブラリ内には、 2 つのモジユールがあります： PrimaryCo'Lor と SecondaryColor という名前の 
2 つの enum を含む、 kinds モジュールと mix という関数を含む utils モジュールです。リスト 14-3 
のようにですね： 

ファイル名： src/lib.rs 


//! # Art 
//! 

// i A library for modeling artistic concepts. 

//! # 芸術 
//! 

//! 芸術的な概念をモデル化するライブラリ。 

pub mod kinds { 

III The primary colors according to the RYB color model. 
Ill RYB カラーモデルによる主色 
pub enum PrimaryColor { 

Red, 

Yellow, 

Blue, 

} 


III The secondary colors according to the RYB color model. 
Ill RYB カラーモデルによる副色 
pub enum SecondaryColor { 

Orange, 

Green, 

Purple, 

} 


pub mod utils { 
use kinds: : ^; 
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III し omhnnes two primary co lots in equal amounts to create 
III a secondary color. 

///2 つの主色を同じ割合で混合し、副色にする 

pub rn mixQcl: PnmaryColor, c2 : PnmaryColor) -> SecondaryColor { 

// --snip-- 

} 

} 

リスト 14-3: kinds と utils モジュールに体系化される要素を含む art ライブラリ 

図 14-3 は、 cargo doc により生成されるこのクレートのドキュメンテーシヨンの最初のページが 
どんな見た目になるか示しています： 

Click or press ‘S’ to search,,?’ for more options... 

Crate art [-] [src] 

H Art 

A library for modeling artistic concepts. 

Modules 

kinds 
utils 


図 14-3: kinds と utils モジュールを列挙する ar * t のドキュメンテーシヨンのトップぺ^ージ 

PrimaryColor •型も SecondaryColor ■型も、 mix 関数もトップページには列挙されていないことに注 
意してください。 kinds と utils をクリックしなければ、参照することができません。 

このライブラリに依存する別のクレートは、現在定義されているモジュール構造を指定して、 art の 
要素をインポートする use 文が必要になるでしょう。リスト 14-4 は、 art クレートから PrimaryColor 
と mix 要素を使用するクレートの例を示しています： 

フアイル名： src / main.rs 

extern crate art; 

use art: : kinds: : PnmaryColor; 
use art::utils :: mix; 


Crate art 


Modules 

Crates 

art 
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# Art 

A library tor modeling artistic concepts. 


pub use kinds: : PnmaryColor; 
pub use kinds: : SecondaryColor; 
pub use utils: : mix; 

pub mod kinds { 

// snip -- 

} 

pub mod utils { 

// -- snip -- 

} 

リスト 14-5: pub use 文を追加して要素を再エクスポートする 

このクレートに対して cargo doc が生成する API ドキュメンテーションは、これで図 14-4 のよう 
にトップぺージに再エクスポートを列挙しリンクするので、 PrimaryColor 型と SecondaryColor 型と 
mix 関数を見つけやすくします。 


rn main () { 

let red = PnmaryColor: : Red; 
let yellow = PrimaryColor :: Yellow; 
mix(red ， yellow); 

} 

リスト 14-4: 内部構造がエクスポートされて art クレートの要素を使用するクレート 

リスト 14-4 は art クレートを使用していますが、このコードの筆者は、 PrimaryColor が ki nds モ 
ジュールにあり、 mix が utils モジュールにあることを理解しなければなりませんでした。 art クレー 
卜のモジュール構造は、 art クレートの使用者よりも、 art クレートに取り組む開発者などに関係が 
深いです。クレートの一部を kinds モジュールと utils モジュールに体系化する内部構造は、 art ク 
レートの使用方法を理解しようとする人には、何も役に立つ情報を含んでいません。代わりに、開発 
者がどこを見るべきか計算する必要があるので、 art クレートのモジュール構造は混乱を招き、また、 
開発者はモジュール名を use 文で指定しなければならないので、この構造は不便です。 

公開 API から内部体系を除去するために、リスト 14-3 の art クレートコードを変更し 、 pub use 
文を追加して、最上位で要素を再エクスポートすることができます。リスト 14-5 みたいにですね： 

ファイル名： src/lib.rs 


/ / / 
/ / / 
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Crate art 


Click or press ‘S’ to search, 'T for more options... 


Reexports 

Modules 


Crates 


art 


Crate art [-] [src] 

H Art 

A library for modeling artistic concepts. 

Reexports 

pub use kinds: : PrimaryColor; 
pub use kinds: : SecondaryColor; 
pub use utils: : mix; 

Modules 


kinds 

utils 


図 14-4: 再エクスポートを列挙する art のドキュメンテーシヨンのトップページ 

art クレートのユーザは、それでも、リスト 14-4 にデモされているように、リスト 14-3 の内部構 
造を見て使用することもできますし、リスト 14-5 のより便利な構造を使用することもできます。リ 
スト 14-6 に示したようにですね： 

フアイル名： src/main.rs 

extern crate art; 

use art: : PnmaryColor; 
use art :: mix; 

fn mai . n () { 

// --snip-- 

} 


リスト 14-6: art クレートの再エクスポートされた要素を使用するプログラム 


ネストされたモジュールがたくさんあるような場合、最上位階層で pub use により型を再エクス 
ポートすることは、クレートの使用者の経験に大きな違いを生みます。 
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役に立つ API 構造を作ることは、科学というよりも芸術の領域であり、ユーザにとって何が最善の 
API なのか、探究するために繰り返してみることができます 。 pub use は、内部的なクレート構造に 
柔軟性をもたらし、その内部構造をユーザに提示する構造から切り離してくれます。インストールし 
てある他のクレートを見て、内部構造が公開 API と異なっているか確認してみてください。 

14.2.3 Crates . io のアカウントをセットアップする 

クレートを公開する前に、 crates.io のアカウントを作成し、 API トークンを取得する必要があり 
ます。そうするには、 crates.io のホームページを訪れ、 Github アカウントでログインしてくださ 
い。（現状は、 Github アカウントがなければなりませんが、いずれは他の方法でもアカウントを作成 
できるようになる可能性があります。）ログインしたら、 https://crates.io/me/ で自分のアカウント 
の設定に行き、 API キーを取り扱ってください。そして 、 cargo login コマンドを API キーとともに 
実行してください。以下のようにですね： 

$ cargo 10 gin abcderghi ] klmnopqrstuvwxyz 012345 

このコマンドは 、 Cargo に API トークンを知らせ、 ~/. cargo/credentials に口一カルに保存しま 
す。このトークンは、秘密です：他人とは共有しないでください。なんらかの理由で他人と実際に共 
有してしまったら、古いものを破棄して crates.io で新しいトークンを生成するべきです。 

14.2.4 新しいクレートにメタデータを追加する 

アカウントはできたので、公開したいクレートがあるとしましょう。公開前に、 Cargo.toml ファイ 
ルの [ package ] セクションに追加することでクレートにメタデータを追加する必要があるでしょう。 

クレートには、独自の名前が必要でしょう。クレートをローカルで作成している間、クレートの名 
前はなんでもいい状態でした。ところが、 crates.io のクレート名は、最初に来たもの勝ちの精神で付 
与されていますので、一旦クレート名が取られてしまったら、その名前のクレートを他の人が公開す 
ることは絶対できません。もう使われているか、サイトで使いたい名前を検索してください。まだな 
ら、 Cargo.toml ファイルの [ package ] 以下の名前を編集して、名前を公開用に使ってください。以 
下のように： 

ファイル名： Cargo.toml 
[ package ] 

name = " guessing _ game " 

たとえ、独自の名前を選択していたとしても、この時点で cargo publish を実行すると、警告とエ 
ラーが 出ます： 

$ cargo publisn 

Updating registrv https :// github . com / rust - lang / crates . io-index 
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warning: mam rest has no description, license, license-ri ie, documentation, 
homepage or repository. 

(警告： マニフェストに説明、ライセンス、ライセンスファイル、ドキュメンテ ー ショ 
ン、ホームページ、 

リポジトリがありません） 

-_sm p-- 

error: api errors : missing or empty metadata fields: description, license. 

( エラー： API エラー：存在しないメタデータフィールド： description, license) 

原因は、大事な情報を一部入れていないからです：説明とライセンスは、他の人があなたの クレー 
卜は何をし、どんな条件の元で使っ ていいの かを知るために必要なのです。 このェラーを 解消するに 
は、 Cargo . toml ファイルに この 情報を入れ込む必要があります。 

1 文か 2 文程度の説明をつけてください。これは、検索結果に表示されますからね。 license フィー 
ルドには、ライセンス識別子を与える必要があります。 Linux 団体の Software Package Data 
Exchange(SPDX) に、この値に使用できる識別子が列挙されています。例えば、自分のクレートを 
MIT ライセンスでライセンスするためには、 MIT 識別子を追加してください： 

ファイル名： Cargo.toml 


[package] 

name = "guessing_game" 
license = "MIT" 

SPDX に出現しないライセンスを使用したい場合、そのライセンスをファイルに配置し、プロジェ 
タトにそのファイルを含め、それから license キーを使う代わりに、そのファイルの名前を指定する 
のに license-file を使う必要があります。 

どのライセンスが自分のプロジェクトに相（ふ）応（さわ）しいかというガイドは、この本の範疇を 
超えています。 Rust コミュニティの 多くの人間は、 MIT OR Apache-2.0 のデュアルライセンスを使 
用することで、 Rust 自体と同じようにプロジェクトをライセンスします。この実践は、 OR で区切ら 
れる複数のライセンス識別子を指定して、プロジヱクトに複数のライセンスを持たせることもできる 
ことを模擬しています。 

独自の名前、バージョン、クレート作成時に cargo new が追加した筆者の詳細、説明、ライセンス 
が追加され、公開準備のできたプロジェクト用の Cargo.toml ファイルは以下のような見た目になっ 
ていることでしよう： 

ファイル名： Cargo.toml 

[package] 

name = "guessing_game" 
version = "0.1.0" 

authors = ["Your Name <you@example.com> u ] 

description = "A fun game where you guess what number the computer has chosen. M 
( コンピュータが選択した数字を言い当てる面白いゲーム） 

"MIT OR Apache-2.0" 


license = 
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[ dependencies 」 

Cargo のドキュメンテーションには、指定して他人が発見し、より容易くクレートを使用できるこ 
とを保証する他のメタデータが解説されています。 

14.2 .5 Crates . io に公開する 

アカウントを作成し、 API トークンを保存し、クレートの名前を決め、必要なメタデータを指定し 
たので、公開する準備が整いました！クレートを公開すると、特定のバージョンが、 crates.io に他 
の人が使用できるようにアップロードされます。 

公開は永久なので、クレートの公開時には気をつけてください。バージョンは絶対に上書きできず、 
コードも削除できません。 crates.io の 一つの 主な目標が、 crates.io のクレートに依存している全て 
のプロジェクトのビルドが、動き続けるようにコードの永久アーカイブとして機能することなのです。 
バージョン削除を可能にしてしまうと、その目標を達成するのが不可能になってしまいます。ですが、 
公開できるクレートバージョンの数に制限はありません。 

再度 cargo publish コマンドを実行してください。今度は成功するはずです： 

$ cargo publish 

Updating registry https :// github . com / rust - lang / crates . io-index 
Packaging guessing_game v 0.1.0 ( file : /// projects / guessing _ game ) 

Verifying guessing_game v 0.1.0 ( file :/// projects / guessi . ng _ game ) 

Compiling guessing_game v 0.1.0 

( file :/// projects / guessing _ game / target / package / guessing _ game -0.1.0) 

Finished dev [unoptimized + debuginfo ] target ( s ) in 0.19 secs 
Uploading guessing_game v 0.1.0 ( file :/// projects / guessing _ game ) 


おめでとうございます！ Rust コミュニティとコードを共有し、誰でもあなたのクレートを依存と 
して簡単に追加できます。 

14.2.6 既存のクレートの新バージョンを公開する 

クレートに変更を行い、新バージョンをリリースする準備ができたら、 Cargo.toml ファイルに指 
定された version の値を変更し、再公開します。セマンティックバージョンルールを使用して加えた 
変更の種類に基づいて次の適切なバージョン番号を決定してください。そして 、 cargo publish を実 
行し、新バージョンをアップロードします。 

14.2 .7 cargo yank で Crates . io からバージョンを削除する 

以前のバージョンのクレートを削除することはできないものの、新しい依存として将来的にプロ 
ジエタトに追加することを防ぐことはできます。ある理由により、クレートパージョンが壊れている 
場合に有用です。そのような場面において、 Cargo はクレートバージョンの取り下げをサポートして 
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います。 

バージョンを取り下げると、他の既存のプロジェクトには、引き続きダウンロードし、そのバー 
ジョンに依存させ続けつつ、新規プロジェクトが新しくそのバージョンに依存しだすことを防ぎます。 
本質的に取り下げは、 Cargo.lock が存在するプロジェクトは全て壊れないことを意味し、将来的に 
Cargo.lock ファイルが生成されるものは、取り下げられたバージョンを使わないのです。 

あるバージョンのクレートを取り下げるには 、 cargo yank を実行し、取り下げたいバージョンを指 
定します： 

$ cargo yank --vers 1.0.1 

- undo を コマンドに 付与する ことで、 取り下げを取り消し、再度あるバージョ ンに プロジェクトを 
依存させ始める こともで きます： 

5 cargo vank --vers 1.0.1 --undo 

取り下げは、コードの削除は一切しません。例として、取り下げ機能は、誤ってアップロードされ 
た秘密鍵を削除するためのものではありません。もしそうなってしまったら、即座に秘密鍵をリセッ 
卜しなければなりません。 

14.3 Cargo のワークスペース 

第12章で、バイナリクレートとライブラリクレートを含むパッケージを構築しました。プロジェ 
タトの開発が進むにつれて、ライブラリクレートの肥大化が続き、その上で複数のライブラリクレー 
卜にパッケージを分割したくなることでしょう。この場面において、 Cargo はワークスべースという 
協調して開発された関連のある複数のパッケージを管理するのに役立つ機能を提供しています。 

14.3.1 ワークスペースを生成する 

ワークスべースは、同じ Cargo.lock と出カディレクトリを共有する一連のパッケージです。ワー 
クスペースを使用したプロジェクトを作成し、ワークスペースの構造に集中できるよう、瑣末なコー 
ドを使用しましょう。ワークスペースを構築する方法は複数ありますが、一般的な方法を提示しま 
しょう。バイナリ1つとライブラリ2つを含むワークスペースを作ります。バイナリは、主要な機能 
を提供しますが、2つのライブラリに依存しています。一方のライブラリは、 add _ one 関数を提供し、 
2番目のライブラリは、 add _ two 関数を提供します。これら3つのクレートが同じワークスペースの 
一部になります。ワークスペース用の新しいディレクトリを作ることから始めましょう： 

$ mkdir add 
$ cd add 

次に add ディレクトリにワークスペース全体を設定する Cargo.toml ファイルを作成します。こ 
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のファイルには、他の CargO.toml ファイルで見かけるような [ package ] セクションやメタデータ 
はありません。代わりにバイナリクレートへのパスを指定することでワークスペースにメンバを追加 
させてくれる [ workspace ] セクションから開始します；今回の場合、そのパスは adder です： 

ファイル名： Cargo.toml 


[ workspace ] 

members = [ 

" adder ", 

] 

次に、 add ディレクトリ内で cargo new を実行することで adder バイナリクレートを作成しま 
しょう： 

$ cargo new --bin adder 

Created binary ( application ) adder project 

この時点で、 cargo build を走らせるとワークスペースを構築できます。 add ディレクトリに存在 
するファイルは、以下のようになるはずです： 

I - Cargo . lock 

I - Cargo.toml 

I - adder 

| | - Cargo.toml 

| 1 - src 

| 1 - main.rs 

1 - target 

ワークスペースには、コンパイルした生成物を置けるように最上位に target のディレクトリが 
あります； adder クレートには target ディレクトリはありません。 adder ディレクトリ内部から 
cargo build を走らせることになっていたとしても、コンパイルされる生成物は、 add / adder/target 
ではなく、 add/target に落ち着くでしょう。ワークスペースのクレートは、お互いに依存しあうこ 
とを意味するので、 Cargo はワークスペースの target ディレクトリをこのように構成します。各 
クレートが target ディレクトリを持っていたら、各クレートがワークスペースの他のクレートを 
再コンパイルし、 target ディレクトリに生成物がある状態にしなければならないでしょう。一つの 
target ディレクトリを共有することで、クレートは不必要な再ビルドを回避できるのです。 

14.3 .2 ワークスぺース内に2番目のクレートを作成する 

次に、ワークスペースに別のメンバクレートを作成し、 add-one と呼びましょう。最上位の 
Cargo.toml を変更して members リストで add-one パスを指定するようにしてください： 


フアイル名： Cargo.toml 
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[ workspace 」 

members = [ 
" adder " , 
" add - one ", 


それから、 add - one という名前のライブラリクレートを生成してください: 


^ cargo new add-one 

Created liorary add-one project 

これで add ディレクトリには、以下のディレクトリやファイルが存在するはずです： 

I - Cargo . lock 

I - Cargo.toml 

| - add-one 

| | - Cargo.toml 

| 1 - src 

| 1 - lib.rs 

I - adder 

| | - Cargo.toml 

| 1 - src 

| 1 - main.rs 

1 - target 

add - one / src / lib.rs ファイルに add _ one 関数を追加しましょう： 

フアイル名： add-one/src/lib.rs 

pub fn add _ one ( x : - i 32) -> i 32 { 
x + 1 

} 

ワークスペースにライブラリクレートが存在するようになったので、バイナリクレート adder ■をライ 
ブラリクレートの add - one に依存させられます。まず、 add - one へのパス依存を adder/Cargo .toml 
に追加する必要があります： 

ファイル名： adder/Cargo.toml 

[ dependencies 」 

add-one = { path = "../ add - one " } 

Cargo はワークスペースのクレートが、お互いに依存しているとは想定していないので、クレート 
間の依存関係について明示する必要があります。 

次に、 adder クレートの add - one クレートから add _ one 関数を使用しましょう。 adder / src / maill.rs 
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ファイルを開き、冒頭に extern crate 行を追加して新しい add - one ライブラリクレートを スコープ 
に導入してください。それから main 関数を変更し、 add _ one 関数を呼び出します。リスト 14-7 のよ 
うにです ね： 

フアイル名： adaer/src/main.rs 

extern crate add _ one ; 

fn main () { 

let num =10; 

// こんにちは世界！ {}+1 は {} ! 

println ! (" Hello , world ! {} plus one is {}!" , num , add _ one : : add _ one ( num )); 

} 

リスト 14-7: adder クレートから add - one ライブラリクレートを使用する 


最上位の add デイレクトリで cargo build を実行することでワークスペースをビルドしま 
しょう！ 

$ cargo build 

Compiling add-one v0.1.0 (file:///projects/add/add-one) 

Compiling adder v0.1.0 (tn ie:///projects/add/adder) 

Finished dev [unoptimized + debuginfo] target(s) in 0.68 secs 

add ディレクトリからバイナリクレートを実行するには、 -p 引数とパッケージ名を cargo run と 
共に使用して、使用したいワークスペースのパッケージを指定する必要があります： 

$ cargo run -p adder 

Finished dev [unoptimized + debuginfo 」 target(s)in 0.0 secs 
Running 'target/debug/adder' 

Hello, world!10 plus one is 11! 

これにより、 adder / src / main.rs のコードが実行され、これは add_one クレートに依存してい 


ます。 


14.3 .2.1 ワークスペースの外部クレートに依存する 

ワークスペースには、各クレートのディレクトリそれぞれに Cargo.lock が存在するのではなく、 
ワークスペースの最上位階層にただ 一つの Cargo.lock が存在するだけのことに注目してください。 
これにより、全クレートが全依存の同じバージョンを使用していることが確認されます。 rand クレー 
卜を adder / Cargo.toml と add - one / Cargo.toml ファィルに追加すると、 Cargo は両者をある 
バージョンの rand に解決し、それを 一つの Cargo.lock に記録します。ワークスペースの全クレー 
卜に同じ依存を使用させるということは、ワークスペースのクレートが相互に互換性を常に維持する 
ということになります。 add - one / Cargo.toml フアイルの [dependencies] セクションに rand ク 
レートを追加して、 add-one クレートで rand クレートを使用できます： 
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ファィル名： add - one / Cargo.toml 

[ dependencies 」 
rand = "0.3.14" 

これで、 add - one / src / lib.rs ファイルに extern crate rand ； を追加でき、 add ディレクトリで 
cargo build を実行することでワークスペース全体をビルドすると、 rand クレートを持ってきてコン 
パイルするでしよう： 

$ cargo build 

Updating registrv https :// github . com / rust - l _ ang / crates . io-index 
Downloading rand v 0.3.14 
-- snip -- 

Compiling rand v 0.3.14 

Compiling add-one v 0.1.0 ( file : /// projects / add / add - one ) 

Compiling adder v 0.1.0 (ti ie :/// projects / add / adder ) 

Finished dev [unoptimized + debuginfo ] target ( s ) in 10.18 secs 


さて、最上位の Cargo.lock は、 rand に対する add - one の依存の情報を含むようになりました。 
ですが、 rand はワークスペースのどこかで使用されているにも関わらず、それぞれの Cargo.toml 
ファイルにも、 rand を追加しない限り、ワークスペースの他のクレートでそれを使用することはでき 
ません。例えば、 adder クレートの adder / src / main.rs ファイルに extern crate rand ; を追加す 
ると、エラーが出ます： 

$ cargo build 

Compiling adder v 0.1.0 (ti ie :/// pro ] ects / add / adder ) 
error : use of unstable library feature ' rand ': use ' rand ' from crates.io (see 
issue #27703) 

( エラー：不安定なライブラリの機能 - rand ，を使用しています： crates, io の ' rand ' を使用 
してください） 

-- > adder / src / main . rs :1:1 

I 

1 | extern crate rand ; 

これを修正するには、 adder クレートの CargO . tOml ファイルを編集し、同様にそのクレートが 
rand に依存していることを示してください。 adder クレートをビルドすると、 rand を Cargo.lock 
の adder の依存一覧に追加しますが、 rand のファイルが追加でダウンロー ドされることはありませ 
ん。 Cargo が、ワークスペースの rand を使用するどのクレートも、同じバージョンを使っているこ 
とを確かめてくれるのです。ワークスペース全体で rand の同じバージョンを使用することにより、複 
数のコピーが存在しないのでスペースを節約し、ワークスペースのクレートが相互に互換性を維持す 
ることを確かめます。 

14.3 .2.2 ワークスペースにテストを追加する 

さらなる改善として 、 add one クレート内に add one : : add one 関数のテストを追加しましょう： 
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フアイル名： add - one / src / lib.rs 

pub fn add _ one ( x : i 32) -> i 32 { 
x + 1 

} 


#[cfg(test)] 
mod tests { 

use super : 


#[test] 

fn it _ works () { 

assert _ eq ! (3, add _ one (2)); 

} 


では、最上位の add ディレクトリで cargo test を実行してください: 


$ cargo test 

し ompiling 

Compiling 
Finished 
Running 


add-one v 0.1.0 ( rile :/// projects / add / add - one ) 
adder v 0.1.0 ( file : /// projects / add / adder ) 
dev [unoptimized + debuginfo ] target ( s ) in 0.27 secs 
target / debug / deps / add _ one - f 0253159197 f 7841 


running 1 test 

test tests :: it_works ... ok 


test result : ok .1 passed ; 0 failed ; 0 ignored ; 0 measured ; 0 filtered out 
Running target / debug / deps / adder - f 88 af 9 d 2 ccl 75 a 5 e 
running 0 tests 

test result : ok . 0 passed ; 0 failed ; 0 ignored ; 0 measured ; 0 filtered out 
Doc-tests add-one 
running 0 tests 

test result : ok . 0 passed ; 0 failed ; 0 ignored ; 0 measured ; 0 filtered out 

出力の最初の区域が、 add-one クレートの it_works テストが通ったことを示しています。次の区域 
には、 adder クレートにはテストが見つからなかったことが示され、さらに最後の区域には、 add-one 
クレートにドキュメンテーションテストは見つからなかったと表示されています。このような構造 
をしたワークスペースで cargo test を走らせると、ワークスペースの全クレートのテストを実行し 
ます。 

- P フラグを使用し、テストしたいクレートの名前を指定することで最上位ディレクトリから、ワー 
クスペースのある特定のクレート用のテストを実行することもできます： 
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$ cargo test -p aad-one 

Finished dev [unoptimized + debuginfo 」 target ( s)in 0.0 secs 
Running target / debug / deps / add _ one - b 3235 fea 9 al 56 f 74 

running 1 test 

test tests : : it_works ... ok 

test result : ok .1 passed ; 0 failed ; 0 ignored ; 0 measured ; 0 riLtered out 
Doc-tests add-one 
running 0 tests 

test result : ok . 0 passed ; 0 failed ; 0 ignored ; 0 measured ; 0 n Ltered out 

この出力は、 cargo test が add-one クレートのテストのみを実行し、 adder •クレートのテストは実 
行しなかったことを示しています。 

ワークスペースのクレートを https :// crates . io / に公開したら、ワークスペースのクレートは個別 
に公開される必要があります。 cargo publish コマンドには-- all フラグや -p フラグはないので、各 
クレートのディレクトリに移動して、ワークスペースの各クレートを cargo publish して、公開しな 
ければなりません。 

鍛錬を積むために、 add-one クレートと同様の方法でワークスペースに add-two クレートを追加し 
てください！ 

プロ ジヱクトが肥大化してきたら、ワークスペースの使用を考えてみてください：大きな 一つの 
コードの塊よりも、微細で個別のコンポーネントの方が理解しやすいです。またワークスペースにク 
レートを保持することは、同時に変更されることが多いのなら、協調しやすくなることにも繫がり 
ます。 

14.4 cargo install で Crates.io からバイナリをインストール 
する 

cargo i nstall コマンドにより、バイナリクレートを口ー カルにインストールし、使用することが 
できます。これは、システムパッケージを置き換えることを意図したものではありません。即（すな 
わ）ち、 Rust の開発者が、他人が crates.io に共有したツールをインストールするのに便利な方法を 
意味するのです。バイナリターゲットを持つパッケージのみインストールできることに注意してくだ 
さい。バイナリターゲットとは、クレートが src / main . rs ファイルやバイナリとして指定された他 
のファイルを持つ場合に生成される実行可能なプログラムのことであり、単独では実行不可能なもの 
の、他のプログラムに含むのには適しているライブラリターゲットとは一線を画します。通常、ク 
レートには、 README ファイルに、クレートがライブラリかバイナリターゲットか、両方をもつか 
という情報があります。 

cargo i nstall でインストールされるバイナリは全て、インストールのルートの bin フォルダに保 
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持されます。 Rust を rustup を使用し、独自の設定を何も行なっていなければ、このディレクトリは、 
$ HOME /. Cargo/bin になります。 cargo "instaU でインストールしたプログラムを実行できるよう 
にするためには、そのディレクトリが $PATH に含まれていることを確かめてください。 

例えば、第12章で、ファイルを検索する ripgrep という grep ツールの Rust 版があることに触れ 
ました。 Hpgrep をインストールしたかったら、以下を実行することができます： 

$ cargo install ripgrep 

Updating registry https://github.com/rust-lang/crates.io-index 
Downloading ripgrep v0.3.2 
--snip-- 

Compiling ripgrep v0.3.2 

Finished release [optimized + debuginfo] target(s) in 97.91 secs 
Installing -/.cargo/bin/rg 

出力の最後の行が、インストールされたバイナリの位置と名前を示していて、 ripgr 印の場合、 rg 
です。インストールディレクトリが $PATH に存在する限り、前述したように、 rg --help を走らせて、 
より高速で Rust らしいファイル検索ツールを使用し始めることができます！ 

14.5 独自のコマンドで Cargo を拡張する 

Cargo は変更する必要なく、新しいサブコマンドで拡張できるように設計されています。$ path に 
あるバイナリが cargo-somethi ng という名前なら、 cargo somethi ng を実行することで、 Cargo のサ 
ブコマンドであるかのように実行することができます。このような独自のコマンドは、 cargo —list 
を実行すると、列挙もされます。 cargo install を使用して拡張をインストールし、それから組み込 
みの Cargo ツール同様に実行できることは、 Cargo の設計上の非常に便利な恩恵です！ 

14.6 まとめ 

Cargo で crates.io と コードを 共有することは、 Rust の エコシステムを 多くの異なる作業に有用 
にするものの一部です。 Rust の標準ライブラリは、小さく安定的ですが、クレートは共有および使 
用しやすく、言語とは異なるタイムラインで進化します。積極的に crates.io で自分にとって有用な 
コードを 共有してください；他の誰かにとっても、役に立つものであることでしょう！ 
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15： 


スマートポインタ 


ポインタは、メモリのアドレスを含む変数の一般的な概念です。このアドレスは、何らかの他の 
データを参照、または「指します」。 Rust において、最もありふれた種類のポインタは、参照であり、 
第 4 章で習いましたね。参照は、&記号で示唆され、指している値を借用します。データを参照する 
こと以外に特別な能力は何もありません。また、オーバーヘッドもなく、最も頻繁に使われる種類の 
ポインタです。 

一方、 スマート ポインタは、ポインタのように振る舞うだけでなく、追加のメタデータと能力があ 
るデータ構造です。スマートポインタという概念は、 Rust に特有のものではありません：スマートポ 
インタは、 C++ に端を発し、他の言語にも存在しています。 Rust では、標準ライブラリに定義され 
た色々なスマートポインタが、参照以上の機能を提供します。この章で探究する一つの例が、参照 力 
ウント方式のスマートポインタ型です。このポインタにより、所有者の数を追いかけることでデータ 
に複数の所有者を持たせることができ、所有者がいなくなったら、データの片付けをしてくれます。 

所有権と借用の概念を使う Rust で、参照とスマートポインタの別の差異は、参照はデータを借用 
するだけのボインタであることです；対照的に多くの場合、スマートポインタは指しているデータを 
所有します。 

その時は、スマートポインタとは呼ばなかったものの、第8章の String や Vec < T > のように、この 
本の中でいくつかのスマートポインタに遭遇してきました。これらの型はどちらも、あるメモリを所 
有し、それを弄ることができるので、スマートポインタに数えられます。また、メタデータ（キャパシ 
ティなど）や追加の能力、あるいは保証 ( String ならデータが常に有効な UTF -8 であると保証するこ 
となど）もあります。 

スマートポインタは普通、構造体を使用して実装されています。スマートポインタを通常の構造体 
と区別する特徴は、スマートポインタは、 Deref と Drop トレイトを実装していることです。 Deref 卜 
レイトにより、スマートポインタ構造体のインスタンスは、参照のように振る舞うことができるので、 
参照あるいはスマートポインタのどちらとも動作するコードを書くことができます。 Drop トレイトに 
より、スマートポイ ン タのイ ン スタンスがスコープを外れた時に走るコードをカスタマイズすること 
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ができます。この章では、どちらのトレイトについても議論し、これらのトレイトがスマートポイン 
夕にとって重要な理由を説明します。 

スマート ボインタパターンが Rust においてよく使われる一般的なデザインパターンだとして、こ 
の章では、全ての既存の スマート ポインタを講義しません。多くのライブラリに独自の スマート ボイ 
ンタがあり、自分だけの スマート ポインタを書くことさえできます。標準ライブラリの最もありふれ 
た スマート ボインタを講義します： 

• ヒープに値を確保する Box く T > 

• 複数の所有権を可能にする参照カウント型の Rc < T > 

• RefCeU < T > を通してアクセスされ、コンパイル時ではなく実行時に借用規則を強制する型の 
Ref < T > と RefMut < T > 


さらに、不変な型が、内部の値を可変化する API を晒す内部可変性パターンについても講義しま 
す。また、循環参照についても議論します：循環参照により、メモリがリークする方法とそれを回避 
する方法です。 

さあ、飛び込みましょう！ 

15.1 ヒープの データを指す Box < T > を使用する 

最も素直なスマートポインタはボックスであり、その型は Box < T > と記述されます。ボックスによ 
り、スタックではなくヒープにデータを格納することができます。スタックに残るのは、ヒープデー 
夕へのポインタです。スタックとヒープの違いを再確認するには、第4章を参照されたし。 

ボックスは、データをスタックの代わりにヒープに格納する以外は、パフォーマンスのオーバー 
ヘッドはありません。しかし、多くのおまけの能力もありません。以下のような場面で最もよく使用 
するでしよう： 

•コンパイル 時にはサイズを知ることができない型があり、正確なサイズを要求する文脈でその 
型の値を使用する時 

•多くのデータがあり、所有権を転送したいが、そうする時にデータがコピーされないことを確 
認する時 

• 値を所有する必要があり、特定の型ではなく特定のトレイトを実装する型であることのみ気に 
かけている時 


「ボックスで再帰的型を可能にする」節の最初の場面を模擬します。2番目の場合、多くのデータの 
所有権を転送するには、データがスタック上でコピーされるので、長い時間がかかり得ます。この場 
面でパフォーマンスを向上させるには、多くのデータをヒープ上にボックスとして格納することがで 
きます。そして、参照しているデータはヒープ上の1箇所に留まりつつ、少量のポインタのデータの 
みをスタック上でコピーするのです。3番目のケースは、トレイトオブジェクトとして知られ、第17 
章は、その話題だけに「トレイトオブジェクトで異なる型の値を許容する」1節全体を捧げています。 
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従って、ここで学ぶことは、第17章でまた適用するでしょう！ 

15.1.1 Box く T > を使ってヒープにデータを格納する 

Box < T > のこのユースケースを議論する前に、記法と Box < T > 内に格納された値と相互作用する方法 
について講義しましょう。 

リスト 15-1 は、ボックスを使用してヒープに i 32 の値を格納する方法を示しています： 

フ アイ ル名： src/main.rs 

fn mann () { 

let b = Box :: new (5); 
println! ("b = {}" , b ); 

} 

リスト 15-1: ボックスを使用して 132 の値をヒープに格納する 

変数 b を定義して値 5 を指す Box の値があって、この値はヒープに確保されています。このプログ 
ラムは、 b = 5 と出力するでしょう；この場合、このデータがスタックにあるのと同じような方法で 
ボックスのデータにアクセスできます。あらゆる所有された値同様、 b が main の終わりでするように 
ボックスがスコープを抜けたら、メモリから解放されます。メモリの解放は（スタックに格納されて 
いる）ボックスと（ヒープに格納されている）指しているデータに対して起きます。 

ヒープに単独の値を置くことはあまり有用ではないので、このように単独でボックスを使用するこ 
とはあまりありません。単独の i 32 のような値を規定で格納される場所であるスタックに置くこと 
が、大多数の場合にはより適切です。ボックスがなかったら定義することの叶わない型をボックスが 
定義させてくれる場合を見ましょう。 

15.1.2 ボックスで再帰的な型を可能にする 

コンパイル時に、コンパイラは、ある型が取る領域を知る必要があります。コンパイル時にサイズ 
がわからない型の1つは、 再帰的な 型であり、これは、型の一部として同じ型の他の値を持つもので 
す。この値のネストは、理論的には無限に続く可能性があるので、コンパイラは再帰的な型の値が必 
要とする領域を知ることができないのです。しかしながら、ボックスは既知のサイズなので、再帰的 
な型の定義にボックスを挟むことで再帰的な型を存在させることができるのです。 

コン スリス トは関数型プログラミング言語では一般的なデータ型ですが、これを再帰的な型の例と 
して探究しましょう。我々が定義するコンスリストは、再帰を除いて素直です；故に、これから取り 
掛かる例の概念は、再帰的な型が関わるもっと複雑な場面に遭遇したら必ず役に立つでしょう。 
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15.1 .2.1 コンスリストについてもっと詳しく 

コンスリストは、 Lisp プログラミング言語とその方言に由来するデータ構造です。 Lisp では 、 cons 
関数（” construct function” の省略形です）が 2 っの弓 I 数から新しいペアを構成し、この引数は通常、 
単独の値と別のペアからなります。これらのペアを含むペアがリストをなすのです。 

cons 関数の概念は、より一般的な関数型プログラミングの俗語にもなっています： ’’toconsx 
ontoy” は、 俗に要素 x をこの新しい コンテナの 初めに置き、 コンテナ y を続けて新しい コンテナの 
インスタンスを 生成することを意味します。 

コンスリストの各要素は、2つの要素を含みます：現在の要素の値と次の要素です。リストの最後 
の要素は、次の要素なしに NU と呼ばれる値だけを含みます。コンスリストは、繰り返し cons 関数 
を呼び出すことで生成されます。繰り返しの規範事例を意味する標準的な名前は、 Nil です。これは 
第 6 章の” null” や” nil” の概念とは異なることに注意してください。 ’’null” や’’ nil” は、無効だった 
り存在しない値です。 

関数型プログラミング言語は、頻繁にコンスリストを使用するものの、 Rust ではあまり使用されな 
いデータ構造です。 Rust で要素のリストがある場合はほとんどの場合、 Vec < T > を使用するのがより 
よい選択になります。他のより複雑で再帰的なデータ型は、様々な場面で役に立ちますが、コンスリ 
ストから始めることで、大して気を散らすことなく再帰的なデータ型をボックスが定義させてくれる 
方法を探究することができます。 

リスト 15-2 には、コンスリストの enum 定義が含まれています。このコードは、 List 型が既知の 
サイズではないため、まだコンパイルできないことに注意してください。既知のサイズがないことを 
これから模擬します。 

フアイル名： src/main.rs 

enum List { 

Cons ( i 32, List ), 

Nil , 

} 

リスト 15-2: i 32 値のコンスリストデータ構造を表す enum を定義する最初の試行 

注釈：この例のためだけに i 32 値だけを保持するコンスリストを実装します。第 10 章で議論 
したように、ジヱネリクスを使用してどんな型の値も格納できるコンスリストを定義して実装 
することもできたでしよう。 

この List 型を使用してリスト1，2，3を格納すると、リスト 15-3 のコードのような見た目になる 
でしよう： 


ファイル名： src/main.rs 
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use List:: {Cons, Nil}; 
fn mann() { 

let list = Cons(1,Cons(2, Cons(3, Nil))); 

} 

リスト 15-3: い ’st enum を使用してリスト 1 ， 2 ， 3 を格納する 

最初の Cons 値は、 1 と別の List 値を保持しています。この List 値は、 2 とまた別の List 値を保 
持する別の Cons 値です。このい ‘st 値は、 3 と、ついにリストの終端を通知する非再帰的な列挙子の 
Nil になる List 値を保持するまたまた別の Cons 値です。 

リスト 15-3 のコードをコンパイルしようとすると、リスト 15-4 に示したエラーが出ます： 

error[E0072] : recursive type List has infinite size 
( エラー：再帰的な型 'List' は無限のサイズです） 

-- > src/main.rs :1:1 

I 

1 | enum List { 

| aaaaaaaaa recursive type has infirvite size 

2 | Cons(i32, List), 

| - recursive without indirection 

I 

=help : insert indirection (e.g., a 'Box', 'Rc', or '&') at some point to 
make 'List' representable 

( 助言：間接参照（例 ： 'Box ' 、 'Rc 、、あるいは ' &') をどこかに挿入して、 ' ！ _ist ' を表現 
可能にしてください） 

リスト 15-4: 再帰的な enum を定義しようとすると得られる エラー 

エラーは、この型は「無限のサイズである」と表示しています。理由は、再帰的な列挙子を含む List 
を定義したからです：自身の別の値を直接保持しているのです。結果として、コンパイラは、 List 値 
を格納するのに必要な領域が計算できないのです。このエラーが得られた理由を少し嚙み砕きましょ 
う。まず、非再帰的な型の値を格納するのに必要な領域をどうコンパイラが決定しているかを見ま 
しょう。 

15.1 .2.2 非再帰的な型のサイズを計算する 

第6章で enum 定義を議論した時にリスト 6-2 で定義した Message enum を思い出してください: 

enum Message { 

Quit, 

Move { x: i 32 , y : "i32 }, 

Write (String) , 

ChangeColor (i 32 , i32 , "i32), 

} 
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Message 値一つにメモリを確保するために必要な領域を決定するために、コンパイラは、各列挙子 
を見てどの列挙子が最も領域を必要とするかを確認します。コンパイラは、 Message: : Quit は全く領 
域を必要とせず、 Message: : Move は i32 値を2つ格納するのに十分な領域が必要などと確かめます。 
ただ 1 つの列挙子しか使用されないので、 Message 値一つが必要とする最大の領域は、最大の列挙子 
を格納するのに必要になる領域です。 

これをコンパイラがリスト 15-2 の List enum のような再帰的な型が必要とする領域を決定しよ 
うとする時に起こることと比較してください。コンパイラは、 Cons 列挙子を見ることから始め、この 
列挙子には、型 i32 値が一つと型 List の値が一つ保持されます。故に、 Cons は1つの i32 と List 
のサイズに等しい領域を必要とします。 List が必要とするメモリ量を計算するのに、コンパイラは 
Cons 列挙子から列挙子を観察します。 Cons 列挙子は型 i32 を1つと型 List の値1つを保持し、こ 
の過程は無限に続きます。図 15-1 のようにですね。 


Cons 



図 15-1: 無限の Cons 列挙子からなる無限の List 


15.1 .2.3 Box<T > で既知のサイズの再帰的な型を得る 

コンパイラは、再帰的に定義された型に必要なメモリ量を計算できないので、リスト 15-4 ではエ 
ラーを返します。しかし、エラーには確かにこの役に立つ提言が含まれています： 

= help : insert indirection (e.g., a Box , Rc . or & ; at some point to 
make 'List' representable 

この提言において、「間接参照」は、値を直接格納する代わりに、データ構造を変更して値へのボイ 
ンタを代わりに格納することで、値を間接的に格納することを意味します。 

Box<T> はポインタなので、 コンパイ ラには Box<T> が必要とする領域が必ずわかります：ポインタ 
のサイズは、指しているデータの量によって変わることはありません。つまり、別の List 値を直接 
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置く代わりに、 Cons 列挙子の中に Box<T> を配置することができます。 Box<T> は、 Cons 列挙子の中 
ではなく、ヒープに置かれる次の List 値を指します。概念的には、それでも他のリストを「保持す 
る」リストとともに作られたリストがありますが、この実装は今では、要素はお互いの中にあるとい 
うよりも、隣り合って配置するような感じになります。 

リスト 15-2 の List enum の定義とリスト 15-3 の List の使用をリスト 15-5 のコードに変更す 
ることができ、これはコンパイルが通ります： 


ファイル名： src / main.rs 


enum List { 

Cons (i 32 , Box< し ist>), 
Nil, 

} 


use List::{Cons, Nil}; 


fn main() { 


} 


let list = Cons(1, 

Box :: new(Cons(2, 

Box :: new(Cons(3, 

Box :: new(Nil)))))); 


リスト 15-5: 既知のサイズにするために Box<T> を使用する List の定義 


Cons 列挙子は、1 つの 132 のサイズプラスボックスのボインタデータを格納する領域を必要とす 
るでしょう。 Nil 列挙子は、値を格納しないので、 Cons 列挙子よりも必要な領域は小さいです。これ 
で、どんな List 値も i32l つの サイズプラスボックスのポインタデータのサイズを必要とすること 
がわかりました。ボックスを使うことで、無限の再帰的な繰り返しを破壊したので、コンパイラは、 
List 値を格納するのに必要なサイズを計算できます。図 15-2 は、 Cons 列挙子の今の見た目を示して 
います。 
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Cons 


Box 


i32 


usize 


図 15-2: Cons が Box を保持しているので、無限にサイズがあるわけではない List 

ボックスは、間接参照とヒープメモリ確保だけを提供します；他のスマートポインタ型で目撃する 
ような、他の特別な能力は何もありません。これらの特別な能力が招くパフォーマンスのオーバー 
へッドもないので、間接参照だけが必要になる唯一の機能であるコンスリストのような場合に有用に 
なり得ます。より多くのボックスのユースケースは第 17 章でもお見かけするでしょう。 

Box く T > 型は、 Deref トレイトを実装しているので、スマートポインタであり、このトレイトにより 
Box < T > の値を参照のように扱うことができます。 Box < T > 値がスコープを抜けると、 Drop トレイト実 
装によりボックスが参照しているヒープデータも片付けられます。これら2つのトレイトをより詳し 
く探究しましょう。これら2つのトレイトは、この章の残りで議論する他のスマートポインタ型で提 
供される機能にとってさらに重要でしょう。 




第 15 章スマートポインタ 


342 


15.2 Deref トレイトでスマートポインタを普通の参照のように扱う 

Deref トレイトを実装することで参照外し演算子の* (掛け算やグロブ演算子とは対照的に）の振 
る舞いをカスタマイズすることができます。スマートポインタを普通の参照のように扱えるように 
Deref を実装することで、参照に対して処理を行うコードを書き、そのコードをスマートポインタと 
ともにも使用できます。 

まずは、参照外し演算子が普通の参照に対して動作するところを見ましょう。それから Box < T > の 
ように振る舞う独自の型を定義し、参照外し演算子が新しく定義した型に対して参照のように動作し 
ない理由を確認しましょう。 Deref トレイトを実装することでスマートポインタが参照と似た方法で 
動作するようにできる方法を探求します。そして、 Rust の参照外し型強制機能と、それにより参照や 
スマートポインタと協調できる方法を見ます。 


15.2.1 参照外し演算子で値までボインタを追いかける 

普通の参照は1種のポインタであり、ポインタの捉え方の一つが、どこか他の場所に格納された値 
への矢印としてです。リスト 15-6 で、 i 32 値への参照を生成し、それから参照外し演算子を使用して 
参照をデータまで追いかけています： 

フアイル名： src/main.rs 

fn mann() { 
let x = 5; 
let y = & x ; 

assert _ eq ! (5, x ); 
assert _ eq ! (5, * y ); 

} 

リスト 15-6: 参照外し演算子を使用して参照を i 32 値まで追いかける 

変数 x は i 32 値の5を保持しています。 y を x への参照にセットします。 x は5に等しいとアサー 
卜できます。しかしながら、 y の値に関するアサートを行いたい場合、 * y を使用して参照を指してい 
る値まで追いかけなければなりません（そのため参照外しです)。一旦、 y を参照外ししたら、 y が指 
している5と比較できる整数値にアクセスできます。 

代わりに assert _ eq ! (5， y ); と書こうとしたら、こんなコンパイルエラーが出るでしよう： 

error[E0277] : the trait bound ii nteger} : std : : cmp : : Parti alEq<&i_i nteger_h> is 
not satisfied 

(エラー： トレイト境界 ' {integer} : std : : cmp : : Parti alEq く &{i nteger}〉' は満たされてい 
ません） 

-- > src/main.rs :6:5 
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6 | assert_eq ! (5 , y) ; 

| a 八八八八八八八八八八八八八八八八 ca iVt compare ' {integer}' with 、 &{integer }、 

I ^ 

=heLp : the trait 'std: : cmp: : PartialEq<&{integer}>' is not implemented for 
'{integer}' 

( 助言：トレイト ' std : : cmp : : Parti alEq く &{i nteger}〉' は 、 {"i nteger } 、に対して実装され 
ていません） 

参照と数値は異なる型なので、比較することは許容されていません。参照外し演算子を使用して、 
参照を指している値まで追いかけなければならないのです。 

15.2.2 Box<T> を参照のように使う 

リスト 15-6 の コー ドを参照の代わりに Box<T> を使うように書き直すことができます；参照外し演 
算子は、 リスト 15-7 に示したように動くでしょう： 

フアイル名： src/main.rs 

fn mann() { 
let x = 5; 

let y = Box :: new(x); 

assert_eq! (5, x); 
assert_eq! (5, *y); 

} 

リスト 15-7: Box<i32> に対して参照外し演算子を使用する 

リスト 15-7 とリスト 15-6 の唯一の違いは、ここでは、 x の値を指す参照ではなく、 x の値を指す 
ボックスのインスタンスに y をセットしていることです。最後のアサートで参照外し演算子を使用し 
て y が参照だった時のようにボックスのボインタを追いかけることができます。次に、独自のボック 
ス型を定義することで参照外し演算子を使用させてくれる Box<T> について何が特別なのかを探究し 
ます。 


15.2.3 独自の スマー トポインタを定義する 

標準ライブラリが提供している Box < T > 型に似たスマートボインタを構築して、スマートボインタ 
は規定で、参照に比べてどう異なって振る舞うのか経験しましょう。それから、参照外し演算子を使 
う能力を追加する方法に目を向けましょう。 

Box < T > 型は究極的に1要素のタプル構造体として定義されているので、リスト 15-8 は、同じよう 
に MyBox < T > 型を定義しています。また、 Box < T > に定義された new 関数と合致する new 関数も定義し 
ています。 


フアイル名： src/mam.rs 
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struct MyBox く T>(T); 

impl<T> MyBox く T> { 

fn new(x: T) -> MyBox く T> { 

MyBox(x) 

} 

} 

リスト 15-8: MyBox<T> 型を定義する 

MyBox という構造体を定義し、ジェネリック引数の T を宣言しています。自分の型にどんな型の値 
も保持させたいからです。 MyBox 型は、型 T を 1 要素持つタプル構造体です。 MyBox: : new 関数は型 T 
の引数を 1 つ取り、渡した値を保持する MyBox インスタンスを返します。 

試しに リスト 15-7 の main 関数を リスト 15-8 に追加し、 Box<T> の代わりに定義した MyBox<T> 型 
を使うよう変更してみてください。 コンパイ ラは MyBox を参照外しする方法がわからないので、 リス 
卜 15-9 の コー ドは コンパイルできません。 

フ アイ ル名： src/main.rs 

fn mann() { 
let x = 5; 

let y = MyBox :: new(x); 

assert_eq! (5, x); 
assert_eq! (5, *y); 

} 

リスト 15-9: 参照と Box く T> を使ったのと同じように MyBox く T> を使おうとする 

こちらが結果と して 出る コ ンパイ ルエラ ーです： 

error[E0614] : type MvBox<iinteger}> cannot be dereferenced 
( エラー：型 'MyBox く {integer}〉' は参照外しできません） 

-- > src/main.rs :14:19 

I 

14 | assert.eq!(5, *y) ; 

MyBox<T> に参照外しの能力を実装していないので、参照外しできません。 * 演算子で参照外しでき 
るようにするには、 Deref トレイトを実装します。 

15.2.4 Deref トレイトを実装して型を参照のように扱う 

第10章で議論したように、トレイトを実装するには、トレイトの必須メソッドに実装を提供する 
必要があります。 Deref トレイトは標準ライブラリで提供されていますが、 self を借用し、内部の 
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データへの参照を返す deref という1つのメソッドを実装する必要があります。リスト 15-10 には、 
MyBox の定義に追記する Deref の実装が含まれています： 

フアイル名： src/main.rs 

use std :: ops :: Deref ; 

# struct MyBox く T>(T); 

■impl<T> Deref for MyBox<T> { 
type Target = T; 


fn deref (&self) -> &T { 

&self •0 

} 

} 

リスト 15-10: MyBox<T> に Deref を実装する 

type Target = T; という記法は、 Deref トレイトが使用する関連型を定義しています。関連型は、 
ジェネリック引数を宣言する少しだけ異なる方法ですが、今は気にする必要はありません；第19章で 
より詳しく講義します。 

deref メソッドの本体を &self• 0 で埋めているので、 deref は*演算子でアクセスしたい値への参 
照を返します。リスト 15-9 の MyBox<T> に*を呼び出す main 関数はこれでコンパイルでき、アサー 
卜も通ります！ 

Deref がなければ、コンパイラは&参照しか参照外しできなくなります。 deref メソッドによりコン 
パイラは、 Deref を実装するあらゆる型の値を取り、 deref メソッドを呼び出して参照外しの仕方を 
知っている&参照を得る能力を獲得するのです。 

リスト 15-9 に* y を入力した時、水面下でコンパイラは、実際にはこのようなコードを走らせてい 
ました： 


*(y.deref()) 


コンパイラは、 * 演算子を deref メソッド、それから何の変哲もない参照外しの呼び出しに置き換 
えるので、 deref メソッドを呼び出す必要があるかどうかを考える必要はないわけです。この Rust 
の機能により、普通の参照か Deref を実装した型があるかどうかに関わらず、等しく機能するコード 
を書かせてくれます。 

deref メソッドが値への参照を返し、 *(y.deref()) のかっこの外の何の変哲もない参照外しがそれ 
でも必要な理由は、所有権システムです。 deref メソッドが値への参照ではなく、値を直接返したら、 
値は self から外にムーブされてしまいます。今回の場合や、参照外し演算子を使用する多くの場合 
には MyBox<T> の中の値の所有権を奪いたくはありません。 

* 演算子は、 コードで * を打つたびに、ただ 1 回、 deref メソッドの呼び出し、そして*演算子の呼 
び出しに置き換えられることに注意してください。 * 演算子の置き換えは、無限に繰り返されないの 
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で、型 1_32 に行き着き、リスト 15-9 で assert_eq! の 5 と合致します。 

15.2.5 関数やメソッドで暗黙的な参照外し型強制 

参照外し型強制は、コンパイラが関数やメソッドの実引数に行う便利なものです。参照外し型強制 
は、 Deref を実装する型への参照を Deref が元の型を変換できる型への参照に変換します。参照外し 
型強制は、特定の型の値への参照を関数やメソッド定義の引数型と一致しない引数として関数やメ 
ソッドに渡すときに自動的に発生します。一連の deref メソッドの呼び出しが、提供した型を引数が 
必要とする型に変換します。 

参照外し型強制は、関数やメソッド呼び出しを書くプログラマが&や*を多くの明示的な参照や参 
照外しとして追記する必要がないように、 Rust に追加されました。また、参照外し型強制のおかげで 
参照あるいはスマートポインタのどちらかで動くコードをもっと書くことができます。 

参照外し型強制が実際に動いていることを確認するため、リスト 15-8 で定義した MyBox < T > と、リ 
スト 15-10 で追加した Deref の実装を使用しましょう。リスト 15-11 は、文字列スライス引数のあ 
る関数の定義を示しています： 

フアイル名： src / main.rs 


rn hello ( name : & str ) i 

println ! (" Hello , {}!" , name ); 

} 

リスト 15 -lll 型 & str * の引数 name のある hello 関数 

hello 関数は、文字列スライスを引数として呼び出すことができます。例えば、 hello (” Rust ”） な 
どです。参照外し型強制により、 hello を型1^8(^<51:鬥叹> の値への参照とともに呼び出すことがで 
きます。リスト 15-12 のようにですね： 

フアイル名： src/main.rs 

# use std :: ops :: Deref ; 

# 

# struct MyBox く T >( T ); 

# 

# impl < T > MyBox く T > { 

# fn new ( x : T ) -> MyBox く T > { 

# MyBox ( x ) 

# } 

# } 

# 

# impl く T > Deref for MyBox く T > { 

# type Target = T ; 

# 

# fn deref (& self ) -> &T { 
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mainu { 

let m = My Box : : new(Stn ng : : from (" Rust ") ); 
hello (& m ); 


リスト 15-12: hello を MyBox<String> 値とともに呼び出し、参照外し型強制のおかけで動く 

ここで、 hello 関数を弓 I 数 &m とともに呼び出しています。この引数は、 MyBox く String 〉 値への参照 
です。リスト 15-10 で MyBox<T> に Deref トレイトを実装したので、コンパイラは deref を呼び出す 
ことで、 &MyBox く String 〉 を &StHng に変換できるのです。標準ライブラリは、 String に文字列スラ 
イスを返す Deref の実装を提供していて、この実装は、 Deref の API ドキュメンテーションに載って 
います。コンパイラはさらに deref を呼び出して、 &String を &str に変換し、これは hello 関数の定 
義と合致します。 

Rust に参照外し型強制が実装されていなかったら、リスト 15-12 のコードの代わりにリスト 15-13 
のコードを書き、 ■^yBoxCtring 〉 の値で hello を呼び出さなければならなかったでしよう。 

フアイル名： src / main.rs 

# use std :: ops :: Deref ; 

# 

# struct MyBox く T>(T); 

# 

# impl く T> MyBox く T> { 

# fn new(x: T) -> MyBox く T> { 

# MyBox(x) 

# } 

# } 

# 

# impl<T> Deref for MyBox<T> { 

# type Target = T; 

# 

# fn deref(&self) -> &T { 

# &self .0 

# } 

# } 

# 

# fn hello(name: &str) { 

# println! ("Hello, {}!" , name); 


# & self .0 

# } 

# } 

# 

# fn hello ( name : & str ) { 

# println ! (" Hello , {}!" , name ); 

# } 
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fn main() { 

let m = My Box :: new(Stn ng: : from ("Rust") ); 
heUo(&(*m) [••]); 

} 

リスト 15-13: Rust に参照外し型強制がなかった場合に書かなければならないであろうコード 

(*m) が MyBox<String> を String に参照外ししています。そして、&と [_.] により、文字列全体 
と等しい String の文字列スライスを取り、 hello のシグニチャと一致するわけです。参照外し型強 
制のないコードは、これらの記号が関係するので、読むのも書くのも理解するのもより難しくなりま 
す。参照外し型強制により、コンパイラはこれらの変換を自動的に扱えるのです。 

Deref トレイトが関係する型に定義されていると、コンパイラは、型を分析し必要なだけ Deref :: 
deref を使用して、参照を得、引数の型と一致させます。 Deref : : deref が挿入される必要のある回 
数は、コンパイル時に解決されるので、参照外し型強制を活用するための実行時の代償は何もありま 
せん。 


15.2.6 参照外し型強制が可変性と相互作用する方法 

Deref トレイトを使用して不変参照に対して*をオーバーライドするように、 DerefMut トレイトを 
使用して可変参照の*演算子をオーバーライドできます。 

以下の3つの場合に型やトレイト実装を見つけた時にコンパイラは、参照外し型強制を行います： 

• T: Deref<Target=U> の時、 &T から &U 

• T : Deref Mu t<Target=U> の時 、 &mut T から &mut U 

• T : Deref<Target=U> の時、 &mut T から &U 

前者 2 つは、可変性を除いて一緒です。最初のケースは、 &T があり、 T が何らかの型 U への Deref 
を実装しているなら、透過的に &U を得られると述べています。2番目のケースは、同じ参照外し型強 
制が可変参照についても起こることを述べています。 

3番目のケースはもっと巧妙です： Rust はさらに、可変参照を不変参照にも型強制するのです。で 
すが、逆はできません：不変参照は、絶対に可変参照に型強制されないのです。借用規則により、可 
変参照があるなら、その可変参照がそのデータへの唯一の参照に違いありません（でなければ、プロ 
グラムは コンパイルで きません)。1つの可変参照を1つの不変参照に変換することは、借用規則を絶 
対に破壊しません。不変参照を可変参照にするには、そのデータへの不変参照がたった1つしかない 
ことが必要ですが、借用規則はそれを保証してくれません。故に、不変参照を可変参照に変換するこ 
とが可能であるという前提を敷けません。 
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15.3 Drop トレイトで片付け時にコードを走らせる 

スマートポインタパターンにとって重要な 2 番目のトレイトは、 Drop であり、これのおかげで値が 
スコープを抜けそうになった時に起こることをカスタマイズできます。どんな型に対しても Drop 卜 
レイトの実装を提供することができ、指定したコードは、ファイルやネットワーク接続などのリソー 
スを解放するのに活用できます。 Drop をスマートポインタの文脈で導入しています。 Drop トレイト 
の機能は、ほぼ常にスマートポインタを実装する時に使われるからです。例えば、 Box<T> は Drop を 
カスタマイズしてボックスが指しているヒープの領域を解放しています。 

ある言語では、プログラマがスマートポインタのインスタンスを使い終わる度にメモリやリソース 
を解放するコードを呼ばなければなりません。忘れてしまったら、システムは詰め込みすぎになりク 
ラッシュする可能性があります。 Rust では、値がスコープを抜ける度に特定のコードが走るよう指定 
でき、コンパイラはこのコードを自動的に挿入します。結果として、特定の型のインスタンスを使い 
終わったプログラムの箇所全部にクリーンアップコードを配置するのに配慮する必要はありません。 
それでもリソースをリークすることはありません。 

Drop トレイトを実装することで値がスコープを抜けた時に走るコードを指定してください。 Drop 
トレイトは、 self への可変参照を取る drop という 1 つのメソッドを実装する必要があります。いつ 
Rust が drop を呼ぶのか確認するために、今は println !文のある drop を実装しましょう。 

リスト 15-14 は、唯一の独自の機能が、インスタンスがスコープを抜ける時に Dropping 
CustomSmartPointer !と出力するだけの、 CustomSmartPointer 構造体です。この例は、コンパイ 
ラがいつ drop 関数を走らせるかをデモしています。 

フアイル名： src / main.rs 


struct CustomSmartPointer { 
data : String, 

} 

impl Drop for CustomSmartPointer { 
fn drop(&mut self) { 

// CustomSmartPoi nter をデータ ' {} 'とともにドロップするよ 

pnntln! ("Dropping CustomSmartPointer with data {} !" , self. data); 



fn main() { 

let c = CustomSmartPoi nter { data : String: : fr*om("my stuff") } ; //俺の 

もの 

let d = CustomSmartPoi nter { data : String: : from("other stuff") }; // 另 IJ の 

もの 

println! ("CustomSmartPointers created. ; // 

CustomSmartPoi nter が生成された 


} 
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リスト 15-14: クリーンアップコードを配置する Drop トレイトを実装する CustomSmartPoi nter 構 
造体 

Drop トレイトは、初期化処理に含まれるので、インポートする必要はありません。 
CustomSmartPointer に Drop トレイトを実装し、 println !を呼び出す drop メソッドの実装 
を提供しています。 drop 関数の本体は、自分の型のインスタンスがスコープを抜ける時に走らせたい 
あらゆるロジックを配置する場所です。ここで何らかのテキストを出力し、コンパイラがいつ drop 
を呼ぶのかデモしています。 

mai n で、 CustomSmartPoi nter のインスタンスを2つ作り、それから CustomSmartPoi nters created 
• と出力しています。 main の最後で、 CustomSmartPoi nter のインスタンスはスコープを抜け、コン 
パイラは最後のメッセージを出力しながら、 drop メソッドに置いたコードを呼び出します。 drop メ 
ソッドを明示的に呼び出す必要はなかったことに注意してください。 

このプログラムを実行すると、以下のような出力が出ます： 


CustomSmartPointers created. 

Dropping CustomSmartPointer with data other stuff ! 

Dropping CustomSmartPointer with data 'my stuff'! 

インスタンスがスコープを抜けた時に指定したコードを呼び出しながらコンパイラは、 drop を自動 
的に呼び出してくれました。変数は、生成されたのと逆の順序でドロップされるので、 d は c より先 
にドロップされました。この例は、 drop メソッドの動き方を見た目で案内するだけですが、通常は、 
メッセージ出力ではなく、自分の型が走らせる必要のあるクリーンアップコードを指定するでしょう。 

15.3.1 std : : mem : : drop で早期に値をドロップする 

残念ながら、自動的な drop 機能を無効化することは、単純ではありません。通常、 drop を無効化 
する必要はありません； Drop トレイトの最重要な要点は、自動的に考慮されることです。ですが、時 
として、値を早期に片付けたくなる可能性があります。一例は、ロックを管理するスマートポインタ 
を使用する時です：同じスコープの他のコードがロックを獲得できるように、ロックを解放する drop 
メソッドを強制的に走らせたくなる可能性があります。 Rust は、 Drop トレイトの drop メソッドを手 
動で呼ばせてくれません；スコープが終わる前に値を強制的にドロップさせたいなら、代わりに標準 
ライブラリが提供する std:: mem: : drop 関数を呼ばなければなりません。 

リスト 15-14 の main 関数を変更して手動で Drop トレイトの drop メソッドを呼び出そうとした 
ら、コンパイルエラーになる でしょう。リスト 15-15 のようにですね： 

フアイル名： src / main.rs 
fn mann() { 

let c = CustomSmartPointer { data : Stri ng: : from ("some data") }; 
println! ("CustomSmartPointer created. ; 
c.dropO ; 
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// main の終端の前に CustomSmartPointer がドロップされた 
println ! ("CustomSmartPointer dropoed before the ena of main . 11 ); 

} 

リスト 15-15： Drop トレイトから drop メソッドを手動で呼び出し、早期に片付けようとする 

このコードをコンパイルしてみようとすると、こんなエラーが出ます： 

error [ E 0040] : explicit use of destructor metnod 
( エラー： デストラクタメソッドを明示的に使用しています） 

-- > src / main . rs :14:7 

I 

14 | c.dropO ; 

| aaaa explicit destructor calls not allowed 

明示的に drop を呼び出すことは許されていないことをこのエラーメッセージは述べています。エ 
ラーメッセージはデストラクタという専門用語を使っていて、これは、インスタンスを片付ける関数 
の一般的なプログラミング専門用語です。デストラクタは、コンストラクタに類似していて、これは 
インスタンスを生成します。 Rust の drop 関数は、1種の特定のデストラクタです。 

コンパイラはそれでも、 main の終端で値に対して自動的に drop を呼び出すので、 drop を明示的に 
呼ばせてくれません。コンパイラが2回同じ値を片付けようとするので、これは二重解放エラーにな 
るでしよう。 

値がスコープを抜けるときに drop が自動的に挿入されるのを無効化できず、 drop メソッドを明示 
的に呼ぶこともできません。よって、値を早期に片付けさせる必要があるなら、 std : : mem : :drop 関数 
を使用できます。 

std : : mem : : drop 関数は、 Drop トレイトの drop メソッドとは異なります。早期に強制的にドロップ 
させたい値を引数で渡すことで呼びます。この関数は初期化処理に含まれているので、リスト 15-15 
の main を変更して drop 関数を呼び出せます。リスト 15-16 のようにですね： 

フアイル名： src / main.rs 

# struct CustomSmartPointer { 

# data : String , 

# } 

# 

# impl Drop for CustomSmartPointer * { 

# fn drop(&mut self ) { 

# println! ("Dropping CustomSmartPointer ! ") ; 

# } 

# } 

# 

fn main () { 

let c = CustomSmartPointer { data : String : : from("some data ") }; 
println! ("CustomSmartPointer created . ; 
drop ( c ); 

// CustomSmartPoi nter ■は mai n が終わる前にドロップされた 
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println ! ("し ustomSmartPointer dropped before the end of main ."); 

} 

リスト 15-16: 値がスコープを抜ける前に明示的にドロップするために std : : mem : : drop を呼び 
出す 

このコードを実行すると、以下のように出力されます： 


CustomSmartPointer created . 

Dropping CustomSmartPointer with data some data ! 

CustomSmartPointer dropped before the end of main . 

Dropping CustomSmartPoi nter with data ' some data '! というテキストが、 CustomSmartPoi nter 
created •と CustomSmartPoi nter dropped before the end of main . テキストの間に出力される 
ので、 drop メソッドのコードがその時点で呼び出されて c をドロップしたことを示しています。 

Drop トレイト実装で指定されたコードをいろんな方法で使用し、片付けを便利で安全にすること 
ができます：例を挙げれば、これを使用して独自のメモリアロケータを作ることもできるでしょう！ 
Drop トレイトと Rust の所有権システムがあれば、コンパイラが自動的に行うので、片付けを覚えて 
おく必要はなくなります。 

まだ使用中の値を間違って片付けてしまうことに起因する問題を心配する必要もなくて済みます: 
参照が常に有効であると確認してくれる所有権システムが、値が最早使用されなくなった時に d rop 
が1回だけ呼ばれることを保証してくれるのです。 

これで Box < T > とスマートポインタの特徴の一部を調査したので、標準ライブラリに定義されてい 
る他のスマートポインタをいくつか見ましょう。 

15.4 Rc < T > は、参照カウント方式の スマー トポインタ 

大多数の場合、所有権は明らかです：一体どの変数が与えられた値を所有しているかわかるのです。 
ところが、単独の値が複数の所有者を持つ可能性のある場合もあります。例えば、グラフデータ構造 
では、複数の辺が同じノー ドを指す可能性があり、概念的にそのノー ドはそれを指す全ての辺に所有 
されるわけです。指す辺がなくならない限り、ノードは片付けられるべきではありません。 

複数の所有権を可能にするため、 Rust には rc < t > という型があり、これは、 reference count- 
ing (参照カウント）の省略形です。 rc < t > 型は、値がまだ使用中かどうか決定する値への参照の数を 
追跡します。値への参照が0なら、どの参照も無効にすることなく、値は片付けられます。 

Rc < T > を家族部屋のテレビと想像してください。 1 人がテレビを見に部屋に入ったら、テレビをつ 
けます。他の人も部屋に入ってテレビを観ることができます。最後の人が部屋を離れる時、もう使用 
されていないので、テレビを消します。他の人がまだ観ているのに誰かがテレビを消したら、残りの 
テレビ視聴者が騒ぐでしょう！ 

ヒープにプログラムの複数箇所で読む何らかのデータを確保したい時に Rc < T > 型を使用し、 コン 
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パイル時には、どの部分が最後にデータを使用し終わるか決定できません。どの部分が最後に使用し 
終わるかわかれば、単にその部分をデータの所有者にして、コンパイル時に強制される普通の所有権 
ルールが 効果を発揮するでしょう。 

Rc < T > は、シングルスレツドの筋書きで使用するためだけのものであることに注意してください。 
第16章で並行性について議論する時に、マルチスレッドプログラムで参照カウントをする方法を講 
義します。 


15.4.1 Rc < T > でデータを共有する 

リスト 15-5 のコンスリストの例に回帰しましよう。 Box < T > を使って定義したことを思い出してく 
ださい。今回は、両方とも3番目のリストの所有権を共有する2つのリストを作成します。これは概 
念的には図 15-3 のような見た目になります： 



図 15-3: 3番目のリスト、 a の所有権を共有する2つのリスト、 b と c 

5と10を含むリスト a を作ります。さらにもう2つリストを作ります： 3で始まる b と4で始ま 
る c です。 b と c のどちらもそれから5と10を含む最初の a リストに続きます。換言すれば、どち 
らのリストも5と10を含む最初のリストを共有しています。 

List の定義を使用して Box < T > とともにこの筋書きを実装しようとしても、うまくいきません〇リ 
スト 15-17 のようにですね： 

フアイル名： src / main.rs 

enum List { 

Cons ( i 32 , Box < し ist >), 

Nil , 

} 

use List ::{ Cons , Nil }; 


fn main () { 
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let a = Cons (5, 

Box :: new ( Cons (10 , 

Box :: new (Nil)))) ; 
let b = Cons (3, Box :: new ( a )); 
let c = Cons (4, Box :: new ( a )); 

} 

リスト 15-17： 3 番目のリストの所有権を共有しようとする Box<T> を使った2つのリストを存在さ 
せることはできないとデモする 

このコードをコンパイルすると、こんなエラーが出ます： 


error*[E0382] : use of moved value: a 
--> src/main.rs:13:30 


1 

12 | 

let b 

=Cons(3, Box : 

: new (.a;); 


1 



- value 

moved here 

13 | 

let c 

=Cons(4 ， Box : 

: new (.a;); 


1 

1 



A value 

used here after move 


=note : move occurs because 'a' has type 'List', which does not implement 
the 'Copy' trait 

Cons 列挙子は、保持しているデータを所有するので、 b リストを作成する時に、 a が b にムーブさ 
れ、 b が a を所有します。それから c を作る際に再度 a を使用しようとすると、 a はムーブ済みなの 
で、できないわけです。 

Cons 定義を代わりに参照を保持するように変更することもできますが、そうしたら、ライフタイ 
ム引数を指定しなければなりません。ライフタイム引数を指定することで、リストの各要素が最低 
でもリスト全体と同じ期間だけ生きることを指定することになります。例えば、借用チヱッカーは 
let a = Cons(10, &Nil) ; を コンパイル させてくれません。一■時的な Nit 値が、 a が参照を得られる 
より前にドロップされてしまうからです。 

代わりに、 List の定義をリスト 15-18 のように、 Box<T> の箇所に Rc<T> を使うように変更します。 
これで各 Cons 列挙子は、値と List を指す Rc<T> を保持するようになりました。 b を作る際、 a の所 
有権を奪うのではなく、 a が保持している Rc<List> をクローンします。それによって、参照の数が1 
から2に増え、 a と b にその Rc<List> にあるデータの所有権を共有させます。また、 c を生成する際 
にも a をクローンするので、参照の数は2から3になります。 Rc: : clone を呼ぶ度に、 Rc<List> 内 
のデータの参照カウントが増え、参照が0にならない限りデータは片付けられません。 

フアイル名： src/main.rs 

enum List { 

Cons (i 32 , Rc く List 〉）， 

Nil, 

} 
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use List :: { Cons , Nil }; 
use std :: re :: Rc ; 

fn main () { 

let a = Rc :: new ( Cons (5, Rc :: new ( Cons (10, Rc :: new ( Nil )))))； 
let b = Cons (3, Rc : : clone (& a )); 
let c = Cons (4, Rc : : clone (& a )); 

} 

リスト 15-18: Rc < T > を使用する List の定義 

初期化処理に含まれていないので、 use 文を追加して Rc < T > をスコープに導入する必要があります。 
main で5と10を保持するリストを作成し、 a の新しい Rc<Li st > に格納しています。それから、匕と 
c を作成する際に、 Rc :: clone 関数を呼び出し、引数として a の Rc < List > への参照を渡しています。 

Rc : : clone (& a ) ではなく 、 a • clone () を呼ぶこともできますが、 Rust のしきたりは、この場合 
Rc : : clone を使うことです。 Rc : : clone の実装は、多くの型の clone 実装のように、全てのデータの 
ディープコピーをすることではありません。 Rc :: clone の呼び出しは、参照カウントをインクリメン 
卜するだけであり、時間はかかりません。データのディープコピーは時間がかかることもあります。 
参照カウントに Rc :: clone を使うことで、視覚的にディープコピーをする類のクローンと参照カウン 
卜を増やす種類のクローンを区別することができます。コード内でパフォーマンスの問題を探す際、 
ディープコピーのクロー ンだけを考慮し、 Rc : : clone の呼び出しを無視できるのです。 

15.4.2 Rc < T > をクローンすると、参照カウントが増える 

a の Rc < List > への参照を作ったりドロップする毎に参照カウントが変化するのが確かめられるよ 
うに、リスト 15-18 の動く例を変更しましょう。 

リスト 15-19 で、リスト c を囲む内側のスコープができるよう main を変更します；そうすれば 、 c 
がスコープを抜けるときに参照カウントがどう変化するか確認できます。 

フアイル名： src / main.rs 

# enum List i 

# Cons ( i 32, Rc < Li st >), 

# Nil , 

# } 

# 

# use List : : { Cons , Nil }; 

# use std :: rc : : Rc ; 

# 

fn main () { 

let a = Rc :: new ( Cons (5, Rc :: new ( Cons (10, Rc : : new ( Nil ))))); 

// a 生成後のカウント ={} 

println! ("count after creating a = {}" , Rc : : strong _ count (& a )); 
let b = Cons (3, Rc :: clone (& a )); 

// b 生成後のカウント = {} 
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pnntln ! ("count after creating b = {}" , Rc : : strong _ count (& a ;); 

{ 

let c = Cons (4, Rc : : clone (& a )); 

// c 生成後のカウント ={} 

printLn! ("count after creating c = {}" , Rc : : strong _ count (& a )); 

} 

// c がスコープを抜けた後のカウント = {} 

pnntln ! ("count after c goes out of scope = ij -" , Rc : : strong _ count (& a )); 

} 

リスト 15-19: 参照カウントを出力する 

プログラム 内で参照カウントが変更される度に、参照カウントを出力します。参照カウントは、 
Rc : : strong_count 関数を呼び出すことで得られます。 Rc く T > 型には weak_count もあるので、この関 
数は count ではなく strong_count と命名されています； weak_count の使用目的は、「循環参照を回避 
する」節で確かめます。 

このコードは、以下の出力をします： 

count after creating a =1 
count after creating b = 2 
count after creating c = 3 
count after c goes out of scope = 2 

a の Rc < List > は最初 1 という参照カウントであることがわかります；そして、 clone を呼び出す度 
に、カウントは1ずつ上がります。 c がスコープを抜けると、カウントは1下がります。参照カウン 
卜を増やすのに、 Rc : : clone を呼ばなければいけなかったみたいに参照カウントを減らすのに関数を 
呼び出す必要はありません： Rc < T > 値がスコープを抜けるときに Drop トレイトの実装が自動的に参照 
カウントを減らします。 

この例でわからないことは、 b そして a が、 main の終端でスコープを抜ける時に、カウントが0に 
なり、その時点で Rc < List > が完全に片付けられることです。 Rc < T > を使用すると、単独の値に複数の 
所有者を持たせることができ、所有者のいずれかが存在している限り、値が有効であり続けることを 
カウントは保証します。 

不変参照経由で、 Rc < T > は読み取り専用にプログラムの複数箇所間でデータを共有させてくれます。 
Rc < T > が複数の可変参照を存在させることも許可してくれたら、第4章で議論した借用 ルールの 1つ 
を侵害する虞（おそれ）があります：同じ場所への複数の可変借用は、データ競合や矛盾を引き起こす 
ことがあるのです。しかし、データを可変化する能力はとても有用です！次の節では、内部可変性 
パターンと、 Rc < T > と絡めて使用してこの不変性制限を手がけられる RefCelA < T > 型について議論し 
ます。 
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15.5 Ref Cell く T > と内部可変性パターン 

内部可変性は、そのデータへの不変参照がある時でさえもデータを可変化できる Rust でのデザイ 
ンパターンです：普通、この行動は借用規則により許可されません。データを可変化するために、こ 
のパターンは、データ構造内で unsafe コードを使用して、可変性と借用を支配する Rust の通常の規 
則を捻じ曲げています。まだ、 unsafe コードについては講義していません；第19章で行います。た 
とえ、コンパイラが保証できなくても、借用規則に実行時に従うことが保証できる時、内部可変性パ 
ターンを使用した型を使用できます。関係する unsafe コードはそうしたら、安全な API にラップさ 
れ、外側の型は、それでも不変です。 

内部可変性パターンに従う RefCeU<T> 型を眺めてこの概念を探究しましょう。 

15.5.1 RefCell < T > で実行時に借用規則を強制する 

Rc く T> と異なり、 RefCell<T> 型は、保持するデータに対して単独の所有権を表します。では、どう 
して RefCell<T> が Box<T> のような型と異なるのでしょうか？第4章で学んだ借用規則を思い出し 
てくだ さい： 

• いかなる時も（以下の両方ではなく、 ）1 つの可変参照かいくつもの不変参照のどちらかが可能 
になる 

• 参照は常に有効でなければならない。 

参照と Box<T> では、借用規則の不変条件は、 コンパイル 時に強制されています。 RefCell<T> では、 
これらの不変条件は、実行時に強制されます。参照でこれらの規則を破ったら、 コンパイルエラーに 
なりました。 RefCeVL<T> でこれらの規則を破ったら、プログラムはパニックし、終了します。 

コンパイル時に借用規則を精査することの利点は、エラーが開発過程の早い段階で捕捉されること 
と、あらかじめ全ての分析が終わるので、実行パフォーマンスへの影響がないことです。それらの理 
由により、多くの場合でコンパイル時に借用規則を精査することが最善の選択肢であり、これが Rust 
の規定になっているのです。 

借用規則を実行時に代わりに精査する利点は、コンパイル時の精査では許容されない特定のメモリ 
安全な筋書きが許容されることです。 Rust コンパイラのような静的解析は、本質的に保守的です。 
コードの特性には、コードを解析するだけでは検知できないものもあります：最も有名な例は停止性 
問題であり、この本の範疇を超えていますが、調べると面白い話題です。 

不可能な分析もあるので、 Rust のコンパイラが、コードが所有権規則に応じていると確証を得られ 
ない場合、正しいプログラムを拒否する可能性があります；このように、保守的なのです。コンパイ 
ラが不正なプログラムを受け入れたら、ユーザは、コンパイラが行う保証を信じることはできなくな 
るでしょう。しかしながら、コンパイラが正当なプログラムを拒否するのなら、プログラマは不便に 
思うでしょうが、悲劇的なことは何も起こり得ません。コードが借用規則に従っていると確証を得ら 
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れる時に RefCell < T > 型は有用ですが、コンパイラはそれを理解し、保証できません。 

Rc < T > と類似して、 RefCell < T > もシングルスレッドの 筋書きで使用するた めのもので あり、試しに 
マルチスレッドの 文脈で使ってみようとすると、 コンパイル エラーを出します。 RefCelA < T > の 機能を 
マルチスレッドの プログラムで得る方法に ついては、 第16章で語ります。 

こちらに Box < T > ， Rc < T > ， RefCeH < T > を選択する理由を要約しておきます： 

• Rc < T > は、同じデータに複数の所有者を持たせてくれる； Box < T > と RefCell < T > は単独の所 
有者。 

• Box < T > は、不変または可変借用をコンパイル時に精査してくれる； Rc < T > は不変借用のみをコ 
ンパイル時に精査してくれる； RefCelA < T > は、不変または可変借用を実行時に精査してくれる。 

• RefCeH < T > は実行時に精査される可変借用を許可するので、 RefCeU < T > が不変でも、 RefCeVL 
< T > 内の値を可変化できる。 

不変な値の中の値を可変化することは、内部可変性パターンです。内部可変性が有用になる場面を 
見て、それが可能になる方法を調査しましょう。 

15.5.2 内部可変性：不変値への可変借用 

借用規則の結果は、不変値がある時、可変で借用することはできないということです。例えば、こ 
のコー ドは コンパイルできません： 

fn mann () { 
let x = 5; 
let y = &mut x ; 

} 

この コー ドを コンパイ ルしようとしたら、以下のような エラーが 出るでしょう： 

error [ E 0596] : cannot borrow immutable local variable x as mutable 
( エラー： 不変な ローカル 変数 ' x' を可変で借用することはできません） 

-- > src / main . rs :3:18 

I 

2 | let x = 5; 

| - consider changing this to mut x 

3 | let y = &mut x ; 

| A cannot borrow mutably 

ですが、メソッド内で値が自身を可変化するけれども、他のコードにとっては、不変に見えること 
が有用な場面もあります。その値のメソッドの外のコードは、その値を可変化することはできない 
でしょう。 RefCell < T > を使うことは、内部可変性を取得する能力を得る1つの方法です。しかし、 
RefCelA < T > は借用規則を完全に回避するものではありません： コンパイ ラの借用チヱッカーは、内部 
可変性を許可し、借用規則は代わりに実行時に精査されます。この規則を侵害したら、 コンパイルェ 
ラーではなく panic ! になるでしょう。 
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RefCeU < T > を使用して不変値を可変化する実践的な例に取り組み、それが役に立つ理由を確認しま 
しょう。 


15.5.2.1 内部可変性のユースケース：モックオブジェクト 

テストダブルは、テスト中に別の型の代わりに使用される型の一般的なプログラミングの概念です。 
モックオブジェクトは、テスト中に起きることを記録するテストダブルの特定の型なので、正しい動 
作が起きたことをアサートできます。 

編注：テストダブルとは、ソフトウェアテストにおいて、テスト対象が依存しているコンポー 
ネントを置き換える代用品のこと。 

Rust には、他の言語でいうオブジェクトは存在せず、また、他の言語のように標準ライブラリに 
モックオブジェクトの機能が組み込まれてもいません。ですが、同じ目的をモックオブジェクトとし 
て提供する構造体を作成することは確実にできます。 

以下が、テストを行う筋書きです：値を最大値に対して追跡し、現在値がどれくらい最大値に近い 
かに基づいてメッセージを送信するライブラリを作成します。このライブラリは、ユーザが行うこと 
のできる API コールの数の割り当てを追跡するのに使用することができるでしょう。 

作成するライブラリは、値がどれくらい最大に近いかと、いつどんなメッセージになるべきかを追 
いかける機能を提供するだけです。このライブラリを使用するアプリケーションは、メッセージを送 
信する機構を提供すると期待されるでしょう：アプリケーションは、アプリケーションにメッセージ 
を置いたり、メールを送ったり、テキストメッセージを送るなどできるでしょう。ライブラリはその 
詳細を知る必要はありません。必要なのは、提供する Messenger と呼ばれるトレイトを実装している 
何かなのです。リスト 15-20 は、ライブラリのコードを示しています： 

ファイル名： src / lib.rs 

pub trait Messenger i 

fn send (& self , msg : & str ) ; 

} 

pub struct LimitTracker <' a , T : 'a + Messenger 〉{ 
messenger : &'a T , 
value : usi ze , 
max : usize , 

} 

■ impl < ' a , T > LimitTracker < ' a , T > 
where T : Messenger { 

pub fn new ( messenger : & T , max : usize ) -> LimitTracker < T > { 

LimitTracker { 
messenger , 
value : 0, 
max , 

} 
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} 

pub fn set_value(&mut self, value : usize) { 
self .value = value; 

let percentage_of_max = self .value as f64 / self .max as f64; 

if percentage_of_max >= 0.75 && percentage_of_max < 0.9 { 

// 警告：割り当ての 75% 以上を使用してしまいました 

self . messenger. send ("Warm' ng: You've used up over 7596 of your quota ! 

")； 

} else if percentage_of_max >= 0.9 && percentage_of_max < 1.0 { 

// 切迫した警告：割り当ての 90% 以上を使用してしまいました 
self .messenger. send ("Urgent warning: You've used up over 90% of your 
quota! ") ; 

} else if percentage_of_max >=1.0 { 

// エラー： 割り当てを超えています 

self .messenger. send ("Error : You are over your quota!"); 



リスト 15-20： 値が最大値にどれくらい近いかを追跡し、特定のレベルの時に警告するライブラリ 

このコードの童要な部分の1つは、 Messenger トレイトには、 self への不変参照とメッセージのテ 
キストを取る send というメソッドが1つあることです。これが、モックオブジェクトが持つ必要のあ 
るインターフェイスなのです。もう1 つの 童要な部分は、1_ _ 1〇1 _ 11：丁「3〇1<6「の561：_ソ31116メソッドの振 
る舞いをテストしたいということです。 value 引数に渡すものを変えることができますが、 set.value 
はアサートを行えるものは何も返してくれません 。 Li mitTracker * を Messenger トレイトを実装する 
何かと、 max の特定の値で生成したら、 value に異なる数値を渡した時にメッセンジャーは適切なメッ 
セージを送ると指示されると言えるようになりたいです。 

send を呼び出す時にメールやテキストメ ッ セージを送る代わりに送ると指示されたメ ッ セージを 
追跡するだけのモックオブジェクトが必要です。モックオブジェクトの新規インスタンスを生成し、 
モックオブジヱクトを使用する LimitTracker を生成し、 LimitTracker の set _ value を呼び出し、そ 
れからモックオブジェクトに期待しているメッセージがあることを確認できます。リスト 15-21 は、 
それだけをするモックオブジェクトを実装しようとするところを示しますが、借用チェッカーが許可 
してくれません： 

ファイル名： src / lib.rs 

# [ cfg ( test )] 

mod tests { 

use super : ; 

struct MockMessenger { 

sent _ messages : Vec < Stri ng > , 
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} 

impL MockMessenger { 

fn new () -> MockMessenger i 

MockMessenger { sent _ messages : vec ! [] } 



impl Messenger for MockMessenger { 
fn send (& self , message : & str ) { 

self . sent _ messages . push ( St ri ng : : from ( message )); 



#[ test ] 

fn it _ sends _ an _ over _75_ percent _ warning _ message () { 
let mock_messenger = MockMessenger : : new (); 

let mut limit_tracker = LimitTracker :: new (& mock _ messenger , 100) ; 
limit _ tracker . set _ value (80); 

assert _ eq ! ( mock _ messenger . sent _ messages . len (),1); 

} 

} 

リスト 15-21: 借用チヱッカーが許可してくれない MockMessanger を実装しようとする 

このテストコ^ー ドは String の Vec で送信すると指示されたメッセージを追跡する sent_messages 
フィールドのある MockMessenger 構造体を定義しています。また、空のメッセージリストから始ま 
る新しい MockMessenger 値を作るのを便利にしてくれる関連関数の new も定義しています。それか 
ら MockMessenger に Messenger ■トレイトを実装しているので、 LimitTracker に MockMessenger を 
与えられます。 send メソッドの定義で引数として渡されたメッセージを取り、 sent_messages の 
MockMessenger リストに格納しています。 

テストでは、 max 値の75%以上になる何かに value をセットしろと LimitTracker •が指示される 
時に起きることをテストしています。まず、新しい MockMessenger を生成し、空のメッセージリスト 
から始まります 0 そして、新しい LimitTracker を生成し、新しい MockMessenger の参照と100とい 
う max 値を与えます。 LimitTracker の set_value メソッドは80という値で呼び出し、これは100 
の75%を上回っています。そして、 MockMessenger * が追いかけているメッセ^ージのリストが、今は 
1 つの メッセージを含んでいるはずとアサートします。 

ところが、以下のようにこのテストには1つ問題があります： 

error [ E 0596] : cannot borrow immutable field selr . sent_messages as mutable 

( エラー： 不変なフィールド、 self . sent_messages 、を可変で借用できません） 

-- > src / lib . rs :52:13 

I 

51 | fn send (& self , message : & str ) { 
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| - use &mut selr here to make mutable 

52 | self . sent _ messages . push ( String : : from ( message )); 

| aaaaaaaaaaaaaaaaaa ca nnot mutably borrow immutable field 

send メソッドは self への不変参照を取るので、 MockMessenger •を変更してメッセージを追跡でき 
ないのです。代わりに &mut self を使用するというエラーテキストからの提言を選ぶこともできない 
のです。そうしたら、 send のシグニチヤが、 Messenger トレイト定義のシグニチヤと一致しなくなる 
からです（気軽に試してエラーメッセージを確認してください)。 

これは、内部可変性が役に立つ場面なのです！ sent _ messages を RefCell < T > 内部に格納し、そう 
したら send メッセージは、 sent _ messages を変更して見かけたメッセージを格納できるようになる 
でしょう。リスト 15-22 は、それがどんな感じかを示しています： 

ファイル名： src / lib.rs 


# icfg ( test)j 
mod tests { 

use super : ; 

use std :: cell :: RefCell ; 


struct MockMessenger { 

sent _ messages : RefCe LL < Vec < Stri ng >> , 

} 

impl MockMessenger { 

fn new () -> MockMessenger { 

MockMessenger { sent _ messages : RefCell :: new ( vec ![] ) } 



impl Messenger for MockMessenger { 
fn send (& self , message : & str ) { 

self . sent _ messages . borrow _ mut (). push ( String : : from ( message )); 



# 

# 

# 


ft [ test ] 


fn it _ sends _ an _ over _75_ percent _ warning _ message () { 


// 


-srn p —— 


let mock_messenger = MockMessenger : : new (); 

let mut limit_tracker = LimitTracker :: new (& mock _ messenger , 

limit _ tracker . set _ value (75); 


100 ) ; 


} 


assert _ eq ! ( mock _ messenger • sent _ messages . borrow (). len (),1); 


リスト 15-22: 外側の値は不変と考えられる一方で RefCell く T > で内部の値を可変化する 


さて、 sent_messages フイールドは、 Vec く String 〉 ではな く、型 RefCell く Vec く Stri ng >> になりま 
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した。 new 関数で、空のベクタの周りに RefCell < Vec < String >> を新しく作成しています。 

send メソッドの実装については、最初の引数はそれでも self への不変借用で、トレイト定義と合 
致しています。 RefCelA < Vec < String >> の borrow_mut を self . sent_messages に呼び出し、 RefCell く 
Vec < String >> の中の値への可変参照を得て、これはベクタになります。それからべクタへの可変参照 
に push を呼び出して、テスト中に送られるメッセージを追跡しています。 

行わなければならない最後の変更は、アサート内部にあります：内部のベクタにある要素の数を確 
認するため、 RefCell < Vec < Str ' ing >> に borrow を呼び出し、ベクタへの不変参照を得ています。 

RefCeU < T > の使用法を見かけたので、動作の仕方を深掘りしましょう！ 

15.5.2.2 RefCell<T> で実行時に借用を追いかける 

不変および可変参照を作成する時、それぞれ&と &mut 記法を使用します。 RefCelA < T > では、 borrow 
と borrow_mut メソッドを使用し、これらは RefCell < T > に所属する安全な API の~■部です。 borrow 
メソッドは、 スマ ートポインタ型の Ref < T > を返し、 borrow_mut は スマ ートポインタ型の RefMut く T > 
を返します。どちらの型も Deref を実装しているので、普通の参照のように扱うことができます。 

RefCeVL < T > は、現在活動中の Ref < T > と RefMut < T > スマートポインタの数を追いかけます 。 borrow 
を呼び出す度に、 RefCelA < T > は活動中の不変参照の数を増やします。 Ref < T > の値がスコープを抜け 
たら、不変参照の数は1下がります。コンパイル時の借用規則と全く同じように、 RefCell < T > はい 
かなる時も、複数の不変借用または1つの可変借用を持たせてくれるのです。 

これらの規則を侵害しようとすれば、参照のように コンパイル エラーになるのではなく、 RefCeU < T > 
の実装は実行時にパニックするでしょう。リスト 15-23 は、リスト 15-22 の send 実装に対する変更 
を示しています。同じ スコープで 2つの可変借用が活動するようわざと生成し、 RefCeU < T > が実行 
時にこれをすることを阻止してくれるところを説明しています。 

ファイル名： src/lib.rs 


impL Messenger for MockMessenger { 
fn send (& self , message : & str ) { 

let mut one_borrow = self . sent _ messages . borrow _ mut (); 
let mut two_borrow = self . sent _ messages . borrow _ mut (); 

one _ borrow . push ( St ri ng : : from ( message )); 
two _ borrow . push ( St ri ng : : from ( message )); 



リスト 15-23： 同じスコープで 2 つの可変参照を生成して RefCell く T > がパニックすることを確か 
める 

borrow_mut から返ってきた RefMut < T > スマートポインタに対して変数 one_borrow を生成してい 
ます。そして、同様にして変数 two_borrow にも別の可変借用を生成しています。これにより同じス 
コープで2つの可変参照ができ、これは許可されないことです。このテストを自分のライブラリ用に 
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走らせると、リスト 15-23 のコードはエラーなくコンパイルできますが、テストは失敗するでしょう： 

- tests :: 1 t _ sends _ an _ over _75_ percent _ warmng_message stdout - 

thread ' tests :: it _ sends _ an _ over _75_ percent _ warmng _ message ' panicked at 
'already borrowed : BorrowMutError ', src / libcore / result . rs :906:4 
( スレッド ， tests : : it _ sends _ an _ over _75_ percent _ warning _ message , は、 

1 すでに借用されています： BorrowMutError ' , src / libcore/result • rs : 906:4 でパニック 
しました） 

note : Run with ' RUST _ BACKTRACE =1' for a backtrace . 

コードは、 already borrowed : BorrowMutError ■というメッセージとともにパニックしたことに気 
付いてください。このようにして RefCeU < T > は実行時に借用規則の侵害を扱うのです。 

コンパイル 時ではなく実行時に借用 エラーを キャッチするということは、開発過程の遅い段階で 
コー ドの ミスを 発見し、 コー ドをプロダク シヨン にデプロイする時まで発見しない可能性もあること 
を意味します。また、 コンパイル 時ではなく、実行時に借用を追いかける結果として、少し実行時に 
パフォーマンスを 犠牲にするでしょう。しかしながら、 RefCell < T > を使うことで不変値のみが許可さ 
れる文脈で使用しつつ、自身を変更して見かけたメッ セージを 追跡するモックオブジヱクトを書くこ 
とを可能にしてくれます。その代償にも関わらず RefCell < T > を使用して、普通の参照よりも多くの 
機能を得ることができるわけです。 

15.5.3 Rc < T > と RefCell < T > を組み合わせることで可変なデータに複数の所有者 
を持たせる 

RefCeVL < T > の一般的な使用法は、 Rc < T > と組み合わせることにあります。 Rc < T > は何らかのデータ 
に複数の所有者を持たせてくれるけれども、そのデータに不変のアクセスしかさせてくれないことを 
思い出してください。 RefCeU < T > を抱える Rc < T > があれば、複数の所有者を持ち そして、 可変化でき 
る値を得ることができるのです。 

例を挙げれば、 Rc < T > を使用して複数のリストに別のリストの所有権を共有させたリスト 15-18 の 
コンスリストの例を思い出してください。 Rc < T > は不変値だけを抱えるので、一旦生成したら、リス 
卜の値はどれも変更できません。 RefCell < T > を含めて、リストの値を変更する能力を得ましょう。 
RefCelA < T > を Cons 定義で使用することで、リスト全てに格納されている値を変更できることをリス 
卜 15-24 は示しています： 

フアイル名： src / main.rs 

# [ derive ( Debug )] 
enum List { 

Cons ( Rc < RefCell < i 32>> , Rc < List >) , 

Nil , 

} 

use List : : { Cons , Ni 1}; 
use std :: rc :: Rc ; 
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use std :: cell : : RefCell ; 
fn mann () { 

let value = Rc : : new ( RefCell :: new (5)); 

let a = Rc : : new ( Cons ( Rc : : clone (& value ) ， Rc : : new ( Nil ))); 

let b = Cons ( Rc : : new ( RefCell: : new (6)) , Rc : : clone (& a )); 
let c = Cons ( Rc : : new ( RefCell : : new (10)) , Rc :: clone (& a )); 

^ value . borrow _ mut () +=10; 

println! ("a after = {:?}"， a ); 
println ! ("b after = {:?}”， b ); 
println ! ("c after = {:?}’'， c ) ; 

} 


リスト 15-24: Rc < RefCell < i 32>> で可変化できる List を生成する 


Rc < RefCell < i _32>> の インスタンスの 値を生成し、 value という名前の変数に格納しているので、直 
接後ほどアクセスすることができます 0 そして、 a に value を持つ Cons 列挙子で List を生成してい 
ます。 value から a に所有権を移したり、 a が value から借用するのではなく、 a と value どちらに 
も中の5の値の所有権を持たせるよう、 value をクローンする必要があります。 

リスト a を Rc < T > に包んでいるので、リスト b と c を生成する時に、どちらも a を参照できます。 
リスト 15-18 ではそうしていました。 

a 、 b 、 c のリストを作成した後、 value の値に10を足しています。これを value の borrow _ mut を 
呼び出すことで行い、これは、第5章で議論した自動参照外し機能 （ 「->演算子はどこに行ったの？」 
節をご覧ください）を使用して、 Rc < T > を内部の RefCell < T > 値に参照外ししています。 borrow_mut 
メソッドは、 RefMut < T > スマートポインタを返し、それに対して参照外し演算子を使用し、中の値を 
変更します。 

a 、 b 、 c を出力すると、全て5ではなく、変更された15という値になっていることがわかります。 
a after = Cons ( RefCell { value :15 }， Nil ) 

b after = Cons ( RefCell { value : 6 }， Cons ( RefCell { value :15 }， Nil )) 
c after = Cons ( RefCell { value :10 }， Cons ( RefCell { value :15 }, Nil )) 

このテクニックは非常に綺麗です！ RefCeH < T > を使用することで表面上は不変な List 値を持て 
ます。しかし、内部可変性へのアクセスを提供する RefCeVL < T > のメソッドを使用できるので、必要な 
時にはデータを変更できます。借用規則を実行時に精査することでデータ競合を防ぎ、時としてデー 
夕構造でちょっとのスピードを犠牲にこの柔軟性を得るのは価値があります。 

標準ライブラリには、 Cell < T > などの内部可変性を提供する他の型もあり、この型は、内部値への参 
照を与える代わりに、値は CelA < T > の内部や外部へコピーされる点を除き似ています。また Mutex < T > 
もあり、これはスレッド間で使用するのが安全な内部可変性を提供します；第16章で使用することを 
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議論しましょう。標準ライブラリのドキュメンテーションをチヱックして、これらの型の違いを詳し 
く知ってください。 

15.6 循環参照は、メモリをリークすることもある 

Rust のメモリ安全保証により誤って絶対に片付けられることのないメモリ（メモリリークとして知 
られています）を生成してしまうことが困難にはなりますが、不可能にはなりません。 コンパイル 時 
にデータ競合を防ぐのと同じようにメモリリークを完全に回避することは、 Rust の保証の一つでは 
なく、メモリリークは Rust においてはメモリ安全であることを意味します。 Rust では、 Rc<T> と 
RefCell<T> を使用してメモリリークを許可するとわかります：要素がお互いに循環して参照する参照 
を生成することも可能ということです。循環の各要素の参照カウントが絶対に0にならないので、こ 
れはメモリリークを起こし、値は絶対にドロップされません。 

15.6.1 循環参照させる 

リスト 15-25 の List enum の定義と tail メソッドから始めて、どう循環参照が起こる可能性が 
あるのかとその回避策を見ましょう： 


フアイル名： src / mam.rs 

# fn main() {} 
use std :: re:: Rc; 
use std :: cell :: RefCell ; 
use List::{Cons, Nil}; 

#[derive(Debug)] 
enum List { 

Cons (i 32, RefCell く Rc く List 〉〉） ， 

Nil, 

} 

impl List { 

fn tail(&self) -> Option く &RefCel_l く Rc く List>>> { 
match *self { 

Cons し ， ref item) => Some い tem )， 

Nil=> None, 



} 

リスト 15-25： Cons 列挙子が参照しているものを変更できるように RefCeU<T> を抱えているコン 
スリストの定義 


リスト 15-5 の List 定義の別バリエーションを使用しています。 Cons 列挙子の2番目の要素はこ 
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れで RefCeU<Rc<List>> になり、リスト 15-24 のように i32 値を変更する能力があるのではなく、 
Cons 列挙子が指している List 値の先を変えたいということです。また、 tail メソッドを追加して 
Cons 列挙子があるときに 2 番目の要素にアクセスするのが便利になるようにしています。 

リスト 15-26 でリスト 15-25 の定義を使用する main 関数を追加しています。このコードは、 a に 
リストを、 b に a のリストを指すリストを作成します。それから a のリストを変更して b を指し、循 
環参照させます。その流れの中に過程のいろんな場所での参照カウントを示す println ! 文が存在し 
ています。 

フアイル名： src / main.rs 

# use Li st : : {Cons , Nil}; 

# use std :: re:: Rc ; 

# use std :: cell :: RefCell ; 

# #[derive(Debug)] 

# enum List { 

# Cons (i 32, RefCell く Rc<Li st >>) ， 

# Nil, 

# } 

# 

# impl List { 

# fn tail(&self) -> Option く &RefCell く Rc く List>>> { 

# match TifSelf { 

# Cons し ， ref item) => Some (item), 

# Nil=> None, 

# } 

# } 

# } 

# 

fn main() { 

let a = Rc :: new(Cons(5, RefCell: : new(Rc: : new(Nil ))))； 

// a の最初の参照カウント= {} 

pnntln! ("a initial rc count = {}" , Rc :: strong_count(&a)); 

// a の次の要素は ={:?} 

println! ("a next item = { : ?}" , a.tail()); 

let b = Rc :: new(Cons(10, RefCell: : new(Rc: : clone(&a ))))； 

// b 作成後の a の参照カウント= {} 

pn ntln! ("a rc count after b creation = {}" ， Rc :: strong_count(&a)) : 

// b の最初の参照カウント= {} 

pn ntln! ("b initial rc count = {}" , Rc: : strong_count(&b)); 

// b の次の要素 ={:?} 

println! ("b next item = {:?}"， b.tail()); 

if let Some (link) = a.tail(){ 

^link.borrow_mut() = Rc: : clone(&b); 

} 

// a を変更後の b の参照カウント ={} 
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println ! ("b re count after changing a = {}" , Re: : strong_count(&b)); 

// a を変更後の a の参照カウント ={} 

pnntln ! ("a re count after changing a = {}" , Re: : strong_count(&a)); 

// Uncomment the next line to see that we have a cycle; 

// it will overflow the stack 

// 次の行のコメントを外して循環していると確認してください；スタックオーバー 

フローします 

// println! ("a next item = {:?}", a. tail()); // a の次の要素 ={ : ?} 

} 

リスト 15-26: 2 つの List 値がお互いを指して循環参照する 

最初のリストが 5, Nil の List 値を保持する Rc<List> インスタンスを変数 a に生成します。そし 
て、値 10 と a のリストを指す別の List 値を保持する Rc<Li_st> インスタンスを変数 b に生成します。 

a が NU ではなく b を指すように変更して、循環させます。 tail メソッドを使用して、 a の 
RefCeU<Rc<List>> への参照を得ることで循環させて、この参照は変数 link に配置します。それか 
ら RefCell<Rc<List>> の borrow_mut メソッドを使用して中の値を Nil 値を持つ Rc<List> から、 b 
の Rc<List> に変更します。 

最後の println! を今だけコメントアウトしたまま、このコードを実行すると、こんな出力が得ら 
れます： 

a initial re count =1 

a next item = Some(RefCell{ value : Nil}) 
a re count after b creation = 2 
b initial re count =1 

b next item = Some(RefCell{ value : Cons(5, RefCell{ value : Nil}) }) 
b re count after changing a = 2 
a re count after changing a = 2 

a のリストを b を指すように変更した後の a と b の Rc<Li_st> インスタンスの参照カウントは 2 で 
す。 mai n の終端で、コンパイラはまず b をドロップしようとし、 a と b の各 Rc<List> インスタンス 
のカウントを 1 減らします。 

しかしながら、それでも a は b にあった Rc<List> を参照しているので、その Rc<List> のカウント 
は 0 ではなく 1 になり、その Rc<Li_st> がヒープに確保していたメモリはドロップされません。メモ 
リはただ、カウント 1 のままそこに永遠に居座るのです。この循環参照を可視化するために、図 15-4 
に図式を作成しました： 
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図 15-4： お互いを指すリスト a と b の循環参照 

最後の println! のコメントを外してプログラムを実行したら、 a が b を指して、 b が a を指して 
と、スタックがオーバーフローするまでコンパイラはこの循環を出力しようとするでしょう。 

この場合、循環参照を作る直後にプログラムは終了します。この循環の結果は、それほど悲壮なも 
のではありません。しかしながら、より複雑なプログラムが多くのメモリを循環で確保し長い間その 
状態を保ったら、プログラムは必要以上のメモリを使用し、使用可能なメモリを枯渴させてシステム 
を参らせてしまう可能性があります。 

循環参照は簡単にできることではありませんが、不可能というわけでもありません。 Rc<T> 値を含 
む RefCeVL<T> 値があるなどの内部可変性と参照カウントのある型がネストして組み合わさっていた 
ら、循環していないことを保証しなければなりません；コンパイラがそれを捕捉することを信頼でき 
ないのです。循環参照をするのは、自動テストやコードレビューなどの他のソフトウヱア開発手段を 
使用して最小化すべきプログラム上のロジックバグでしょう。 

循環参照を回避する別の解決策は、ある参照は所有権を表現して他の参照はしないというように 
データ構造を再構成することです。結果として、所有権のある関係と所有権のない関係からなる循環 
ができ、所有権のある関係だけが、値がドロップされうるかどうかに影響します。リスト 15-25 で 
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は、常に Cons 列挙子にリストを所有してほしいので、データ構造を再構成することはできません。親 
ノードと子ノードからなるグラフを使った例に目を向けて、どんな時に所有権のない関係が循環参照 
を回避するのに適切な方法になるか確認しましょう。 

15.6.2 循環参照を回避する： Rc < T > を Weak < T > に変換する 

ここまで、 Rc : : clone を呼び出すと Rc < T > インスタンスの strong _ count が増えることと、 
strong _ count が0になった時に Rc < T > インスタンスは片付けられることをデモしてきました。 
Rc : : downgrade を呼び出し、 Rc < T > への参照を渡すことで、 Rc < T > インスタンス内部の値への弱い参照 
(weak reference ) を作ることもできます。 Rc : : downgrade を呼び出すと、型 Weak < T > のスマートポ 
インタが得られます。 Rc < T > インスタンスの strong _ count を1増やす代わりに、 Rc :: downgrade を 
呼び出すと、 weak _ count が1増えます。 strong _ count 同様、 Rc < T > 型は weak _ count を使用して、幾 
つの Weak < T > 参照が存在しているかを追跡します。違いは、 Rc < T > が片付けられるのに、 weak_count 
が0である必要はないということです。 

強い参照は、 Rc < T > インスタンスの 所有権を共有する方法です。弱い参照は、所有権関係を表現し 
ません。ひとたび、関係する値の強い参照カウントが0になれば、弱い参照が関わる循環はなんでも 
破壊されるので、循環参照にはなりません。 

Weak < T > が参照する値はドロップされてしまっている可能性があるので、 Weak < T > が指す値に何か 
をするには、値がまだ存在することを確認しなければなりません。 Weak < T > の upgrade メソッドを呼 
び出すことでこれをしてください。このメソッドは Option < Rc < T >> を返します。 Rc < T > 値がまだド 
ロップされていなければ、 Some の結果が、 Rc < T > 値がドロップ済みなら、 None の結果が得られます。 
upgrade が Option < T > を返すので、コンパイラは、 Some ケースと None ケースが扱われていることを 
確かめてくれ、無効なポインタは存在しません。 

例として、要素が次の要素を知っているだけのリストを使うのではなく、要素が子要素と親要素を 
知っている木を作りましょう。 

15.6.2.1 木データ構造を作る：子ノードのある Node 
手始めに子ノー ドを知っているノー ドのある木を構成します。独自の i 32 値と子供の Node 値への 
参照を抱える Node という構造体を作ります： 

フアイル名： src / main.rs 

use std :: rc :: Rc ; 

use std :: cell :: RefCell ; 

# [derive(Debug)J 
struct Node i 
value : i 32, 

children : RefCell < Vec < Rc < Node >>> , 


} 
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Node に子供を所有してほしく、木の各 Node に直接アクセスできるよう、その所有権を変数と共有 
したいです。こうするために、 Vec く T > 要素を型 Rc く Node > の値になるよう定義しています。どのノー 
ドが他のノードの子供になるかも変更したいので、 Vec < Rc < Node >> の周りの children を RefCell く T > 
にしています。 

次にこの構造体定義を使って値3と子供なしの leaf という1つの Node インスタンスと、値5と 
leaf を子要素の一つとして持つ branch という別のインスタンスを作成します。リスト 15-27 のよう 
にですね： 

フアイル名： src / main.rs 

# use std :: rc :: Rc ; 

# use std :: cell : : RefCell ; 

# 

# # [derive(Debug)] 

# struct Node { 

# value : i 32， 

# children : RefCell < Vec < Rc < Node >>> , 

# } 

# 

fn mai . n () { 

let leaf = Rc :: new(Node { 
value : 3, 

children : RefCell :: new ( vec ![] ), 

})； 

let branch = Rc :: new(Node { 
value : 5, 

children : RefCell :: new ( vec ! [ Rc :: clone (& leaf )]), 

})； 

} 

リスト 15-27： 子供なしの leaf ノードと leaf を子要素に持つ branch ノー ドを作る 

leaf の Rc く Node 〉 をクローンし、 branch に格納しているので、 leaf の Node は leaf と branch とい 
う2つの所有者を持つことになります 。 branch • children を通して branch から leaf へ迪ることはで 
きるものの、 leaf から branch へ迪る方法はありません。涅由は、 leaf には branch への参照がなく、 
関係していることを知らないからです 0 leaf に branch が親であることを知ってほしいです 0 次はそ 
れを行います。 

15.6.2.2 子供から親に参照を追加する 

子供に親の存在を気付かせるために、 Node 構造体定義に parent フィールドを追加する必要があり 
ます。 parent の型を決める際に困ったことになります。 Rc < T > を含むことができないのはわかりま 
す 0 そうしたら 、 leaf • parent が branch を指し 、 branch • children が leaf を指して循環参照になり、 
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strong_count 値が絶対に 0 にならなくなってしまうからです。 

この関係を別の方法で捉えると、親ノードは子供を所有すべきです：親ノードがドロップされたら、 
子ノードもドロップされるべきなのです。ですが、子供は親を所有するべきではありません：子ノー 
ドをドロップしても、親はまだ存在するべきです。弱い参照を使う場面ですね！ 

従って、 Rc<T> の代わりに parent の型を Weak<T> を使ったもの、具体的には RefCell く Weak く Node 〉〉 
にします。さあ、 Node 構造体定義はこんな見た目になりました： 

フアイル名： src / main.rs 

use std :: re :: {Rc , Weak} ; 
use std : :cell:: RefCell; 

#[derive(Debug)] 
struct Node { 
value : i 32 , 

parent : RefCell<Weak<Node>> , 
children : RefCell く Vec く Rc く Node >>> ， 

} 

ノードは親ノードを参照できるものの、所有はしないでしよう。リスト 15-28 で 、 leaf ノードが 
親の branch を参照できるよう、この新しい定義を使用するように mai n を更新します： 

フアイル名： src / main.rs 

# use std :: rc :: {Rc, Weak} ; 

# use std : :cell:: RefCell; 

# 

# #[derive(Debug)] 

# struct Node { 

# value : i32 ， 

# parent : RefCell<Weak<Node>> , 

# children : RefCell く Vec く Rc く Node>>>, 

# } 

# 

fn main() { 

let leaf = Rc :: new(Node { 
value : 3, 

parent : RefCell :: new(Weak: : new()), 
children: RefCell :: new(vec ![] ), 

})； 

// leaf の親 ={:?} 

println! ("leaf parent = {:?}"， leaf.parent.borrow().upgrade()); 

let branch = Rc :: new(Node { 
value : 5, 

parent : RefCell :: new (Weak : :new()), 

children : RefCell :: new (vec ! [Rc :: clone(&leaf )]) ， 


})； 
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a - leaf . parent . borrow _ mut () = Rc : : downgrade (& branch ); 

println! ("leaf parent = { : ?}" , leaf . parent . borrow (). upgrade ()); 

} 

リスト 15-28: 親ノードの branch への弱い参照がある leaf ノード 

leaf ノードを作成することは、 parent フィールドの例外を除いてリスト 15-27 での leaf ノード 
の作成法の見た目に似ています： leaf は親なしで始まるので、新しく空の Weak く Node 〉 参照インスタ 
ンスを作ります。 

この時点で upgrade メソッドを使用して leaf の親への参照を得ようとすると、 None 値になりま 
す。このことは、最初の pH ntln ! 文の出力でわかります： 

leaf parent = None 

branch ノードを作る際、 branch には親ノードがないので、こちらも parent フィールドには新し 
い Weak く Node > 参照が入ります。それでも、 leaf は branch の子供になっています。一^旦 branch に 
Node インスタンスができたら、 leaf を変更して親への Weak く Node 〉 参照を与えることができます 0 
leaf の parent フィールドには、 RefCell く Weak く Node 〉〉 の borrov^mut メソッドを使用して、それから 
Rc : : downgrade 関数を使用して、 branch の Rc く Node 〉 から branch への Weak く Node 〉 参照を作ります。 

再度 leaf の親を出力すると、今度は branch を保持する Some 列挙子が得られます：これで leaf 
が親にアクセスできるようになったのです！ leaf を出力すると、リスト 15-26 で起こっていたよ 
うな最終的にスタックオーバーフローに行き着く循環を避けることもできます； Weak く Node 〉 参照は、 
( Weak ) と出力されます： 

leaf parent = Some(Node { value : 5. parent : RefCeLL { vaLue : ( WeaK ) }, 
children : RefCell { value : [Node { value : 3 ， parent : RefCell { value : ( Weak ) }， 
children : RefCell { value : []}}]} }) 

無限の出力が欠けているということは、このコードは循環参照しないことを示唆します。このこと 
は、 Rc : : str * ong _ count と Rc : : weak _ count を呼び出すことで得られる値を見てもわかります。 

15.6.2.3 strong_count と weak_count への変更を可視化する 

新しい内部スコープを作り、 branch の作成をそのスコープに移動することで、 Rc く Node 〉 インスタ 
ンスの strong _ count と weak _ count 値がどう変化するかを眺めましよう。そうすることで 、 branch 
が作成され、それからスコープを抜けてドロップされる時に起こることが確認できます。変更は、リ 
スト 15-29 に示してあります： 

フアイル名： src / main.rs 
# use std :: rc :: { Rc , Weak } ; 
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# use std :: ce II:: RefCe L L ; 

# 

# # [derive(Debug)] 

# struct Node { 

# value : i 32， 

# parent : RefCell < Weak < Node >> , 

# children : RefCell く Vec く Rc く Node >>> ， 

# } 

林 

fn main () { 

let leaf = Rc :: new(Node { 
value : 3, 

parent : RefCell :: new ( Weak : : new ()), 
children : RefCell :: new ( vec ![] ), 

})； 


println ! ( 

// leaf の strong_count = {}， weak_count = {} 

"leaf strong = {}， weak = {}" , 

Rc : : strong _ count (& leaf ), 

Rc : : weak _ count (& leaf ), 

)； 

{ 

let branch = Rc :: new(Node { 
value : 5, 

parent : RefCell :: new ( Weak : : new ()), 

children : RefCell :: new ( vec ! [ Rc :: clone (& leaf )]), 

})； 

* leaf . parent . borrow _ mut () = Rc : : downgrade (& branch ); 
println ! ( 

// branch の strong_count = {}， weak_count = {} 

"branch strong = {}， weak = {}" , 

Rc : : strong _ count (& branch ), 

Rc : : weak _ count (& branch ), 

)； 

println ! ( 

"leaf strong = {}，weak = {}" , 

Rc : : strong _ count (& leaf ), 

Rc : : weak _ count (& leaf ), 

)； 

} 

println! ("leaf parent = {:?}"， leaf . parent . borrow (). upgrade ()); 
println ! ( 

"leaf strong = {}， weak = {}" , 

Rc : : strong _ count (& leaf ), 

Rc : : weak _ count (& leaf ), 

)； 

} 
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リスト 15-29: 内側のスコープで branch を作成し、強弱参照カウントを調査する 

leaf 作成後、その Rc く Node 〉 の強カウントは1、弱カウントは0になります。内側のスコープで 
branch を作成し、 leaf に紐付け、この時点でカウントを出力すると、 branch の Rc く Node 〉 の強カウ 
ントは1、弱カウントも1になります （leaf • parent が Weak く Node 〉 で branch を指しているため)〇 
leaf のカウントを出力すると、強カウントが2になっていることがわかります。 branch が今は、 
branch . children に格納された leaf の Rc く Node 〉 の クロー ンを持っているからですが、それでも弱力 
ウントは〇でしよう。 

内側のスコープが終わると、 branch はスコープを抜け、 Rc く Node 〉 の強カウントは〇に減るので、 
この Node はドロップされます 。 leaf • parent からの弱カウント1は、 Node がドロップされるか否か 
には関係ないので、メモリリークはしないのです！ 

この スコープの 終端以後に leaf の親にアクセスしようとしたら、再び None が得られます。プ 
ログラムの終端で leaf の Rc く Node 〉 の強カウントは1、弱カウントは0です。変数 leaf が今では 
Rc く Node 〉 への唯一の参照に再度なったからです。 

カウントや値のドロップを管理するロジックは全て、 Rc < T > や Weak く T > とその Drop トレイトの実 
装に組み込まれています。 Node の定義で子供から親への関係は Weak く T > 参照になるべきと指定する 
ことで、循環参照やメモリリークを引き起こさずに親ノードに子ノードを参照させたり、その逆を行 
うことができます。 

15.7 まとめ 

この章は、 スマート ボインタを使用して Rust が規定で普通の参照に対して行うのと異なる保証や 
代償を行う方法を講義しました。 Box < T > 型は、既知のサイズで、ヒープに確保されたデータを指しま 
す。 Rc < T > 型は、ヒープのデータへの参照の数を追跡するので、データは複数の所有者を保有できま 
す。内部可変性のある RefCell < T > 型は、不変型が必要だけれども、その型の中の値を変更する必要 
がある時に使用できる型を与えてくれます；また、コンパイル時ではなく実行時に借用規則を強制し 
ます。 

Deref と Drop トレイトに ついても 議論しましたね。これらは、スマートポインタの多くの機能を可 
能にしてくれます。メモリリークを引き起こす循環参照と Weak < T > でそれを回避する方法も探究しま 
した。 

この章で興味をそそられ、独自のスマートポインタを実装したくなったら、もっと役に立つ情報を 
求めて、 “The Rustonomicon ” をチェックしてください。 

次は、 Rust での並行性に ついて 語ります。もういく つか 新しい スマート ポインタに ついて さえも学 
ぶでしよう。 
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恐れるな！並行性 


並行性を安全かつ効率的に扱うことは、 Rust の別の主な目標です。並行プログラミングは、プログ 
ラムの異なる部分が独立して実行することであり、並列プログラミングはプログラムの異なる部分が 
同時に実行することですが、多くのコンピユータが複数のプロセッサの利点を生かすようになる につ 
れ、重要度を増しています。歴史的に、これらの文脈で行うプログラミングは困難で、エラーが起き 
やすいものでした： Rust はこれを変えると願っています。 

当初、 Rust チームは、メモリ安全性を保証することと、並行性問題を回避することは、異なる方法 
で解決すべき別々の課題だと考えていました。時間とともに、チームは、所有権と型システムは、メ 
モリ安全性と並行性問題を管理する役に立つ一連の強力な道具であることを発見しました。所有権と 
型チヱックを活用することで、多くの並行性エラーは、実行時エラーではなくコンパイル時エラーに 
なります。故に、実行時に並行性のバグが起きた状況と全く同じ状況を再現しようと時間を浪費させ 
るよりも、不正なコードはコンパイルを拒み、問題を説明するエラーを提示するでしょう。結果とし 
て、プロダクトになった後でなく、作業中にコードを修正できます。 Rust のこの方向性を恐れるな！ 
並行性とニックネーム付けしました。これにより、潜在的なバグがなく、かつ、新しいバグを導入す 
ることなく簡単にリファクタリングできるコードを書くことができます。 

注釈：簡潔性のため、並行または並列と述べることで正確を期するのではなく、多くの問題を 
並行と割り切ってしまいます。この本がもし並行性あるいは並列性に関した本ならば、詳述し 
ていたでしょう。この章に対しては、並行を使ったら、脳内で並行または並列と置き換えてく 
ださい。 

多くの言語は、自分が提供する並行性問題を扱う解決策について独断的です。例えば、 Erlang に 
は、メッセージ受け渡しの並行性に関する素晴らしい機能がありますが、スレッド間で状態を共有す 
ることに関しては、曖昧な方法しかありません。可能な解決策の一部のみをサポートすることは、高 
級言語にとっては合理的な施策です。なぜなら、高級言語は一部の制御を失う代わりに抽象化するこ 
とから恩恵を受けるからです。ところが、低級言語は、どんな場面でも最高の パフォーマンスで 解決 
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策を提供すると想定され、ハードウェアに関してほとんど抽象化はしません。そのため、 Rust は、自 
分の状況と必要性に適した方法が何であれ、問題をモデル化するためのいろんな道具を備えています。 
こちらが、この章で講義する話題です： 

• スレッドを生成して、複数のコードを同時に走らせる方法 
• チャンネルがスレッド間でメッセージを送るメッセージ受け渡し並行性 
• 複数のスレッドが何らかのデータにアクセスする状態共有並行性 

• 標準ライブラリが提供する型だけでなく、ユーザが定義した型に対しても Rust の並行性の安 
全保証を拡張する Sync と Send トレイト 


16.1 スレッドを使用してコードを同時に走らせる 

多くの現代の 0 S では、実行中のプログラムのコードはプロセスで走り、 0 S は同時に複数のプロ 
セスを管理します。自分のプログラム内で、独立した部分を同時に実行できます。これらの独立した 
部分を走らせる機能をスレッドと呼びます。 

プログラム内の計算を複数のスレッドに分けると、パフォーマンスが改善します。プログラムが同 
時に複数の作業をするからですが、複雑度も増します。スレッドは同時に走らせることができるので、 
異なるスレッドのコードが走る順番に関して、本来の保証はありません。これは問題を招きます。例 
えば： 

• スレッドがデータやリソースに矛盾した順番でアクセスする競合状態 

• 2つのスレッドがお互いにもう一方が持っているリソースを使用し終わるのを待ち、両者が継 
続するのを防ぐデッドロック 

• 特定の状況でのみ起き、確実な再現や修正が困難なバグ 

Rust は、スレッドを使用する際のマイナスの影響を軽減しようとしていますが、それでも、マルチ 
スレッドの文脈でのプログラミングでは、注意深い思考とシングルスレッドで走るプログラムとは異 
なるコード構造が必要です。 

プログラミング言語に よってスレッドは いくつかの方法で実装されています。多くの 0 S で、新規 
スレッ ドを生成する API が提供されています。言語が 0 S の API を呼び出して スレッ ドを生成する 
このモデルを時に 1:1と 呼び、1つの 0 S スレッ ドに対して1つの言語 スレッ ドを意味します。 

多くのプログラミング言語がスレッドの独自の特別な実装を提供しています。プログラミング言語 
が提供するスレッドは、グリーンスレッドとして知られ、このグリーンスレッドを使用する言語は、 
それを異なる数の 0 S スレッドの文脈で実行します。このため、グリーンスレッドのモデルは M:N 
モデルと呼ばれます： m 個のグリーンスレッドに対して、 N 個の 0 S スレッドがあり、 M と N は必ずし 
も同じ数字ではありません。 

各モデルには、それだけの利点と代償があり、 Rust にとって最も重要な代償は、ランタイムのサ 
ポートです。ランタイムは、混乱しやすい用語で文脈によって意味も変わります。 
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この文脈でのランタイムとは、言語によって全てのバイナリに含まれるコードのことを意味します。 
言語によってこのコードの大小は決まりますが、非アセンブリ言語は全てある量の実行時コードを含 
みます。そのため、口語的に誰かが「ノーランタイム」と言ったら、「小さいランタイム」のことを意 
味することがしばしばあります。ランタイムが小さいと機能も少ないですが、バイナリのサイズも小 
さくなるという利点があり、その言語を他の言語とより多くの文脈で組み合わせることが容易になり 
ます。多くの言語では、より多くの機能と引き換えにランタイムのサイズが膨れ上がるのは、受け入 
れられることですが、 Rust にはほとんどゼロのランタイムが必要でパフォーマンスを維持するため 
に C コードを呼び出せることを妥協できないのです。 

M : N のグリーンスレッドモデルは、スレッドを管理するのにより大きな言語ランタイムが必要で 
す。よって、 Rust の標準ライブラリは、1:1スレッドの実装のみを提供しています。 Rust はそのよ 
うな低級言語なので、例えば、むしろどのスレッドがいつ走るかのより詳細な制御や、より低コスト 
の文脈切り替えなどの一面をオーバーへッドと引き換えるなら、 M : N スレッドの実装をしたクレート 
もあります。 

今や Rust におけるスレッドを定義したので、標準ライブラリで提供されているスレッド関連の 
API の使用法を探究しましょう。 

16.1.1 spawn で新規スレッドを生成する 

新規スレッドを生成するには、 thread : : spawn 関数を呼び出し、新規スレッドで走らせたいコード 
を含むクロージャ（クロージャについては第13章で語りました）を渡します。リスト 16-1 の例は、 
メインスレッドと新規スレッドからテキストを出力します： 

フアイル名： src / main.rs 

use std :: thread ; 

use std : : time : : Duratnon ; 

fn mann () { 

thread :: spawn (|| { 
for i in 1..10 { 

// やあ！立ち上げたスレッドから数字 {} だよ！ 

pnntln ! ("hi number {} from the spawned thread ! 11 , i ); 
thread : : sleep (Du rati on : : from _ rmllis ( l )); 

} 

})； 

for i in 1..5 { 

// メインスレッドから数字 {} だよ！ 

println ! ("hi number {} from the main thread ! 11 ， i ); 
thread :: sleep (Du rati on :: from _ millis (1)); 


} 


} 
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リスト 16-1: メインスレッドが別のものを出力する間に新規スレッドを生成して何かを出力する 


この関数では、新しいスレッドは、実行が終わったかどうかにかかわらず、メインスレッドが終了 
したら停止することに注意してください。このプログラムからの出力は毎回少々異なる可能性があり 
ますが、だいたい以下のような感じでしょう： 


hi 

hi 

hi 

hi 

hi 

hi 

hi 

hi 

hi 


number 1 
number 1 
number 2 
number 2 
number 3 
number 3 
number 4 
number 4 
number 5 


from the 
from the 
from the 
from the 
from the 
from the 
from the 


main thread ! 
spawned thread ! 
main thread ! 
spawned thread ! 
main thread ! 
spawned thread ! 
main thread ! 


from the spawned thread ! 
from the spawned thread ! 


thread : : sleep を呼び出すと、少々の間、スレッドの実行を止め、違うスレッドを走らせることがで 
きます。スレッドはおそらく切り替わるでしょうが、保証はありません： os がスレッドのスケジュー 
ルを行う方法によります。この実行では、コード上では立ち上げられたスレッドの print 文が先に現 
れているのに、メインスレッドが先に出力しています。また、立ち上げたスレッドには i が9になる 
まで出力するよう指示しているのに、メインスレッドが終了する前の5までしか到達していません。 

このコードを実行してメインスレッドの出力しか目の当たりにできなかったり、オーバーラップが 
なければ、範囲の値を増やして 0 S がスレッド切り替えを行う機会を増やしてみてください。 


16.1 .2 join ハンドルで全スレッドの終了を待つ 

リスト 16-1 のコードは、メインスレッドが終了するためにほとんどの場合、立ち上げたスレッド 
がすべて実行され ない だけでなく、立ち上げたスレッドが実行されるかどうかも保証できません。原 
因は、スレッドの実行順に保証がないからです。 

thread : : spawn の戻り値を変数に保存することで、立ち上げたスレッドが実行されなかったり、 
完全には実行されなかったりする問題を修正することができます。 thread : spawn の戻り値の型は 
]oi nHandle です。30 i nHandle は、その join メソッドを呼び出したときにスレッドの終了を待つ所有 
された値です。リスト 16-2 は、リスト 16-1 で生成したスレッドの ] oinHandle を使用し、 join を呼 
び出して、 main が終了する前に、立ち上げたスレッドが確実に完了する方法を示しています： 

フアイル名： src / main.rs 

use std :: thread ; 

use std : : time : : Duratnon ; 

fn mann () { 

let handle = thread :: spawn (|| { 
for i in 1..10 { 

println ! ("hi number {} from the spawned thread ! 11 ， i ); 
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thread :: sleep(Duration: : from_mi l1ts(1)) ; 

} 

})； 

for 1 in 1..5 { 

println! ("hi number {} from the main thread!", i); 
thread :: sleep (Du rati on :: from_millis(1)); 

} 

handle . join () .unwrapO ; 


リスト 16-2: thread: : spawn のコ oinHandle を保存してスレッドが完了するのを保証する 


ハンドルに対して join を呼び出すと、ハンドルが表すスレッドが終了するまで現在実行中のスレッ 
ドをブロックします。スレッドをブロックするとは、そのスレッドが動いたり、終了したりすること 
を防ぐことです。 join の呼び出しをメインスレッドの for ループの後に配置したので、リスト 16-2 
を実行すると、以下のように出力されるはずです： 


hi 

hi 

hi 

hi 

hi 

hi 

hi 

hi 

hi 

hi 

hi 

hi 

hi 


number 

number 

number 

number 

number 

number 

number 

number 

number 

number 

number 

number 

number 


1 from the 

2 from the 

1 from the 

3 from the 

2 from the 

4 from the 

3 from the 

4 from the 

5 from the 

6 from the 

7 from the 

8 from the 

9 from the 


main thread! 
main thread! 
spawned thread! 
main thread! 
spawned thread! 
main thread! 
spawned thread! 
spawned thread! 
spawned thread! 
spawned thread! 
spawned thread! 
spawned thread! 
spawned thread! 


2 つの スレッ ドが代わる代わる実行されていますが、 handle. join() 呼び出しのためにメ インス 
レッ ドは待機し、立ち上げた スレッ ドが終了するまで終わりません。 

ですが、代わりに handle .join () を for ループの前に移動したらどうなるのか確認しましよう。こ 
んな感じに： 


ファイル名： src / main.rs 

use std :: thread ; 

use std :: time : : Duration ; 

rn main () { 

let handle = thread :: spawn (|| { 
for i in 1..10 { 

println ! ("hi number {} from the spawned thread ! 11 , i ); 
thread :: sleep ( Duration : : from _ millis ( l )); 
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})； 


handle .] 〇 1 n () .unwrapO ; 
for 1 in 1..5 { 

println! ("hi number {} from the main thread !", i ); 
thread :: sleep ( Duration : : from _ millis ( l )); 



メインスレッドは、立ち上げたスレッドが終了するまで待ち、それから for * ループを実行するので、 
以下のように出力はもう混ざらないでしょう： 


hi 

hi 

hi 

hi 

hi 

hi 

hi 

hi 

hi 

hi 

hi 

hi 

hi 


number 1 
number 2 
number 3 
number 4 
number 5 
number 6 
number 7 
number 8 
number 9 
number 1 
number 2 
number 3 
number 4 


from the 
from the 
from the 
from the 
from the 
from the 
from the 
from the 
from the 
from the 
from the 
from the 
from the 


spawned thread ! 
spawned thread ! 
spawned thread ! 
spawned thread ! 
spawned thread ! 
spawned thread ! 
spawned thread ! 
spawned thread ! 
spawned thread ! 
main thread ! 
main thread ! 
main thread ! 
main thread ! 


どこで join を呼ぶかといったほんの些細なことが、スレッドが同時に走るかどうかに影響するこ 
ともあります。 


16.1 .3 スレッドで move クロージャを使用する 

move クロージャは、 thread : :spawn とともによく使用されます。あるスレッドのデータを別のス 
レッドで使用できるようになるからです。 

第13章で、クロージャの引数リストの前に move キーワードを使用して、クロージャに環境で使用 
している値の所有権を強制的に奪わせることができると述べました。このテクニックは、ある スレッ 
ドから別の スレッ ドに値の所有権を移すために新しい スレッ ドを生成する際に特に有用です。 

リスト 16-1 において、 thread :: spawn に渡したクロージャには引数がなかったことに注目してく 
ださい：立ち上げたスレッドのコードでメインスレッドからのデータは何も使用していないのです。 
立ち上げたスレッドでメインスレッドのデータを使用するには、立ち上げるスレッドのクロージャは、 
必要な値をキャブチャしなければなりません。リスト 16-3 は、メインスレッドでベクタを生成し、立 
ち上げたスレッドで使用する試みを示しています。しかしながら、すぐにわかるように、これはまだ 
動きません： 
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フアイル名： src / mam.rs 
use std :: thread ; 
fn mann () { 

let v = vec ! [1, 2, 3]; 

let handle = thread :: spawn (|| { 

// こちらがベクタ： {:?} 

println ! (" Here's a vector : {:?}", v ); 

})； 

handle . join () .unwrapO ; 

} 

リスト 16-3: 別のスレッドでメインスレッドが生成したベクタを使用しようとする 

クロージャは v を使用しているので、 V をキャブチャし、クロージャの環境の一部にしています。 
thread : : spawn はこのクロージャを新しいスレッドで走らせるので、その新しいスレッド内で v にア 
クセスできるはずです。しかし、このコードをコンパイルすると、以下のようなエラーが出ます： 

error [ E 0373] : closure may outlive the current function , but it borrows v , 
which is owned by the current function 

(エラー： クロージャは現在の関数よりも長生きするかもしれませんが、現在の関数が所 
有している 

' v ' を借用しています） 

-- > src / mann . rs :6:32 

let handle = thread : : spawn | | { 

aa may outlive borrowed value ' v ' 
println !(" Here 丨 s a vector : {:?}", v ); 

- ' v ' is borrowed here 

help : to force the closure to take ownership of ' v ' (and any other referenced 
variables ), use the ' move ' keyword 

(助言： ' v ' (や他の参照されている変数）の所有権をクロージャに奪わせるには、 ' move ' 

キーワードを使用してください） 

I 

6 | let handle = thread : : spawrn.move 丨| { 

| A A A A A A A 

Rust は v のキャプチャ方法を推論し、 println ! は v への参照のみを必要とするので、クロージャ 
は、 v を借用しようとします。ですが、問題があります：コンパイラには、立ち上げたスレッドがどの 
くらいの期間走るのかわからないので、 v への参照が常に有効であるか把握できないのです。 

リスト 16-4 は、 v への参照がより有効でなさそうな筋書きです： 

フアイル名： src / main.rs 


6 

7 


use std :: thread ; 
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fn mann () i 

let v = vec ! [1, 2, 3]; 

let handle = thread :: spawn (|| { 

println ! (" Here's a vector : {:?}", v ); 

})； 

// いや〜！ 

drop ( v ); // oh no ! 


handle . join (). unwrap (); 

} 

リスト 16-4: v をドロップするメインスレッドから v への参照をキャプチャしようとするクロー 
ジャを伴うスレッド 

このコードを実行できてしまうなら、立ち上げたスレッドはまったく実行されることなく即座に 
バックグラウンドに置かれる可能性があります。立ち上げたスレッドは内部に V への参照を保持して 
いますが、メインスレッドは、第15章で議論した dm P 関数を使用して、即座に v をドロップしてい 
ます。そして、立ち上げたスレッドが実行を開始する時には、 V はもう有効ではなく、参照も不正に 
なるのです。あち ゃ 一！ 

リスト 16-3 のコンパイルエラーを修正するには、エラーメッセージのアドバイスを活用できます： 

help : to force the closure to take ownership of v (and any other rererenced 
variables ), use the ' move ' keyword 

I 

6 | let handle = thread : : spawn(move || { 

| A A A A A A A 

クロージャの前に move キーワードを付することで、 コンパイ ラに値を借用すべきと推論させるの 
ではなく、クロージャに使用している値の所有権を強制的に奪わせます。リスト 16-5 に示したリス 
卜 16-3 に対する変更は、 コンパイル でき、意図通りに動きます： 

フ アイ ル名： src / main.rs 
use std :: thread ; 
fn mann () { 

let v = vec ! [1, 2, 3]; 

let handle = thread : : spawn (move || { 

println ! (" Here*s a vector : {:?}", v ); 

})； 


} 


handle . join (). unwrap (); 
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リスト 16-5： move キーワードを使用してクロージャに使用している値の所有権を強制的に奪わせる 

move クロー ジャを使用していたら、メインスレッドが drop を呼び出すリスト 16-4 のコードはど 
うなるのでしょうか？ move で解決するのでしょうか？残念ながら、違います；リスト 16-4 が試み 
ていることは別の理由によりできないので、違うエラーが出ます。クロージャに move を付与したら、 
v をクロージャの環境に ムーブ するので、最早メイ ン スレッドで drop を呼び出すことは叶わなくなる 
でしょう。代わりにこのようなコンパイルエラーが出るでしょう： 

error*[E0382] : use or moved value: v 

(エラー： ムーブされた値の 使用： 、 v') 

-- > src/main.rs :10:10 

I 

6 | let handle = thread: : spawn(move || { 

| - value moved (into closure) here 

10 | drop(v); // oh no! 

| A value used here after move 

I 

=note : move occurs because 'v' has type 'std: : vec: : Vec<i32>', which does 

not implement the 'Copy' trait 

( 注釈 ： ' v' の型が ' std : : vec : : Vec<i32> ' のためムーブが起きました。この型は 、' Copy 
' トレイトを実装していません） 

再三 Rust の所有権規則が救ってくれました！リスト 16-3 のコードはエラーになりました。コン 
パイラが一時的に保守的になり、スレッドに対して V を借用しただけだったからで、これは、メイン 
スレッドは理論上、立ち上げたスレッドの参照を不正化する可能性があることを意味します。 V の所 
有権を立ち上げたスレッドに移動するとコンパイラに指示することで、メインスレッドはもう V を使 
用しないとコンパイラに保証しているのです。リスト 16-4 も同様に変更したら、メインスレッドで v 
を使用しようとする際に所有権の規則に違反することになります。 move キーワードにより、 Rust の 
保守的な借用のデフォルトが上書きされるのです；所有権の規則を侵害させてくれないのです。 

スレッ ドと スレッ ド API の基礎知識を得たので、 スレッ ドで できる ことを見ていきましょう。 

16.2 メッセージ受け渡しを使ってスレッド間でデータを転送する 

人気度を増してきている安全な並行性を保証する一つのアプローチがメ ッセー ジ受け渡しで、ス 
レッドやアクターがデータを含むメッセージを相互に送り合うことでやり取りします。こちらが 、 Go 
言語のドキユメンテーシヨンのスローガンにある考えです：「メモリを共有することでやり取りする 
な；代わりにやり取りすることでメモリを共有しろ」 

メッセージ送信並行性を達成するために Rust に存在する一つの主な道具は、チャンネルで 、 Rust 
の標準ライブラリが実装を提供しているプログラミング概念です。プログラミングのチャンネルは、 
水の流れのように考えることができます。小川とか川ですね。アヒルのおもちゃやボートみたいなも 
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のを流れに置いたら、水路の終端まで下流に流れていきます。 

プログラミングにおけるチャンネルは、2分割できます：転送機と受信機です。転送機はアヒルの 
おもちゃを川に置く上流になり、受信機は、アヒルのおもちゃが行き着く下流になります。コードの 
ある箇所が送信したいデータとともに転送機のメソッドを呼び出し、別の部分がメッセージが到着し 
ていないか受信側を調べます。転送機と受信機のどちらかがドロップされると、チャンネルは閉じら 
れたと言います。 

ここで、1つのスレッドが値を生成し、それをチャンネルに送信し、別のスレッドがその値を受け 
取り、出力するプログラムに取り掛かります。チャンネルを使用してスレッド間に単純な値を送り、 
機能の説明を行います。一旦、そのテクニックに慣れてしまえば、チャンネルを使用してチャットシ 
ステムや、多くのスレッドが計算の一部を担い、結果をまとめる1つのスレッドにその部分を送るよ 
うなシステムを実装できるでしょう。 

まず、リスト 16-6 において、チャンネルを生成するものの、何もしません。チャンネル越しにど 
んな型の値を送りたいのかコンパイラがわからないため、これはまだコンパイルできないことに注意 
してください。 

フアイル名： src / main.rs 
use std :: sync :: mpsc : 
fn mann () { 

let ( tx , rx ) = mpsc :: channel (); 

# tx . send (()). unwrap (); 

} 

リスト 16-6: チャンネルを生成し、 2 つの部品を tx と rx に代入する 

mpsc ： : channel 関数で新しいチャンネルを生成しています； mpsc は multiple producer, single 
consumer を表しています。簡潔に言えば、 Rust の標準ライブラリがチャンネルを実装している方 
法は、1つのチャンネルが値を生成する複数の送信側と、その値を消費するたった1つの受信側を持 
つことができるということを意味します。複数の小川が互いに合わさって1つの大きな川になるとこ 
ろを想像してください：どの小川を通っても、送られたものは最終的に1つの川に行き着きます。今 
は、1つの生成器から始めますが、この例が動作するようになったら、複数の生成器を追加します。 

mpsc : : channel 関数はタプルを返し、1つ目の要素は、送信側、2つ目の要素は受信側になります。 
tx と rx という略称は、多くの分野で伝統的に転送機と受信機にそれぞれ使用され ている ので、変数 
をそのように名付けて、各終端を示します。タプルを分配するパターンを伴う let 文を使用していま 
す； let 文でパターンを使用することと分配に ついては、 第18章で議論しましょう。このように let 
文を使うと、 mpsc : : channel で返ってくるタプルの部品を抽出するのが便利になります。 

立ち上げたスレッドがメインスレッドとやり取りするように、転送機を立ち上げたスレッドに移動 
し、1文字列を送らせましょう。リスト 16-7 のようにですね。川の上流にアヒルのおもちゃを置いた 
り、チャットのメッセージをあるスレッドから別のスレッドに送るみたいですね。 
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フアイル名： src / mam.rs 

use std :: thread ; 
use std :: sync :: mpsc ; 

fn mann() { 

let (tx, rx) = mpsc :: channel(); 

thread :: spawn (move || { 

let val= String: : from ("hi.") ; 
tx. send (val).unwrapO ; 

»； 

> 

リスト 16-7: tx を立ち上げたスレッドに移動し、「やあ」を送る 

今回も、 thread: :spawn を使用して新しいスレッドを生成し、それから move を使用して、立ち上 
げたスレッドが tx を所有するようにクロージャに tx をムーブしています。立ち上げたスレッドは、 
メッセージをチャンネルを通して送信できるように、チャンネルの送信側を所有する必要があります。 

転送側には、送信したい値を取る send メソッドがあります。 send メソッドは Resul_t<T, E> 型を 
返すので、既に受信側がドロップされ、値を送信する場所がなければ、送信処理はエラーを返します。 
この例では、エラーの場合には、パニックするように unwrap を呼び出しています。ですが、実際のア 
プリケーシヨンでは、ちゃんと扱うでしょう：第9章に戻ってちゃんとしたエラー処理の方法を再確 
認してください。 

リスト 16-8 において、メインスレッドのチャンネルの受信側から値を得ます。アヒルのおもちゃ 
を川の終端で水から回収したり、チャットメッセージを取得するみたいですね。 

フ アイ ル名： src / main.rs 

use std :: thread ; 
use std :: sync :: mpsc ; 

fn mann() { 

let (tx, rx) = mpsc :: channel(); 

thread: : spawn (move || { 

let val= String: : fr*om("hi ") ; 
tx. send (val).unwrapO ; 

})； 

let received = rx. recv() .unwrapO ; 

// 値は {} です 

printIn! ("Got : {}" , received); 

} 


リスト 16-8: 「やあ」の値をメインスレッドで受け取り、出力する 
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チャンネルの受信側には有用なメソッドが2つあります： recv と try _ recv です。 receive の省略 
形である recv を使っています。これは、メインスレッドの実行をブロックし、値がチャンネルを流 
れてくるまで待機します。一旦値が送信されたら、 recv はそれを Result < T , E > に含んで返します。 
チャンネルの送信側が閉じたら、 recv は エラーを 返し、もう値は来ないと通知します。 

try_「ecv メソッドはブロックせず、代わりに即座に Result < T ， E > を返します：メッセージがあっ 
たら、それを含む Ok 値、今回は何もメッセージがなければ、 Err 値です。メッセージを待つ間にこの 
スレッドにすることが他にあれば、 try _ recv は有用です： try _ recv を頻繁に呼び出し、メッセージが 
あったら処理し、それ以外の場合は、再度チェックするまでちょっとの間、他の作業をするループを 
書くことができるでしょう。 

この例では、簡潔性のために recv を使用しました；メッセージを待つこと以外にメインスレッドが 
すべき作業はないので、メインスレッドをブロックするのは適切です。 

リスト 16-8 のコードを実行したら、メインスレッドから値が出力されるところを目撃するで 
しょう： 

Got : hi 

完璧です！ 

16.2.1 チャンネルと所有権の転送 

安全な並行コードを書く手助けをしてくれるので、所有権規則は、メッセージ送信で重要な役割を 
担っています。並行プログラミングでエラーを回避することは、 Rust プログラム全体で所有権につい 
て考える利点です。実験をしてチャンネルと所有権がともに動いて、どう問題を回避するかをお見せ 
しましょう： val 値を立ち上げたスレッドで、チャンネルに送った後に使用を試みます。リスト 16-9 
のコードのコンパイルを試みて、このコードが許容されない理由を確認してください： 

フアイル名： src / main.rs 

use std :: thread ; 
use std :: sync :: mpsc ; 

fn mann () { 

let ( tx , rx ) = mpsc :: channel (); 

thread : : spawn (move || { 

let val = String : : fr * om("hi ") ; 
tx . send ( val ). unwrap (); 

// val は {} 

println! ("val is {}"， val ); 

})； 

let received = rx . recv () . unwrap (); 
println ! (" Got : {}" , received ); 

} 
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リスト 16-9: チヤンネルに送信後に val の使用を試みる 


ここで、 tx.send 経由でチャンネルに送信後に val を出力しようとしています。これを許可するの 
は、悪い考えです：一旦、値が他のスレッドに送信されたら、再度値を使用しようとする前にそのス 
レッドが変更したりドロップできてしまいます。可能性として、その別のスレッドの変更により、矛 
盾していたり存在しないデータのせいでエラーが発生したり、予期しない結果になるでしょう。です 
が、リスト 16-9 のコードのコンパイルを試みると、 Rust はエラーを返します： 


error *[ E 0382] : use of moved value : val 
--> src / main . rs :10:31 


9 

10 


tx . send ( val ). unwrapO ; 

- value moved here 

println!("val is {}", val ); 

aaa value used here after move 

note : move occurs because ' val ' has type ' std : : string : : String ', which does 


not implement the ' Copy ' trait 


並行性のミスがコンパイルエラーを招きました。 send 関数は引数の所有権を奪い、値がムーブされ 
ると、受信側が所有権を得るのです。これにより、送信後に誤って再度値を使用するのを防いでくれ 
ます；所有権システムが、万事問題ないことを確認してくれます。 


16.2.2 複数の値を送信し、受信側が待機するのを確かめる 

リスト 16-8 のコードはコンパイルでき、動きましたが、2つの個別のスレッドがお互いにチャン 
ネル越しに会話して いる ことは、明瞭に示されませんでした。リスト 16-10 において、リスト 16-8 
のコードが並行に動いて いる ことを証明す る 変更を行いました：立ち上げたスレッドは、複数のメッ 
セージを送信し、各メッセージ間で、1秒待機します。 

フアイル名： src / main.rs 

use std :: thread ; 
use std :: sync :: mpsc ; 
use std: : time: : Duration; 

fn mann() { 

let (tx, rx) = mpsc :: channel(); 

thread :: spawn (move || { 

// スレッ ドからやあ （Ivi from the thread) 
let vaIs = vec! [ 

Stri ng: : from ("hi ") , 

Stri ng: : f rom("f rom") , 
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String: : f rom("the") , 

Stri ng: : f rom("thread") , 

]； 

for val in vaIs { 

tx. send (val).unwrapO ; 

thread :: sleep(Duration: : from_secs(l)); 

} 

})； 

for received in rx { 

println! ("Got: {}" , received); 

} 

} 

リスト 16-10: 複数のメッセージを送信し、メッセージ間で停止する 

今回は、メインスレッドに送信したい文字列のベクタを立ち上げたスレッドが持っています。それ 
らを繰り返し、各々個別に送信し、 Duration の値 1 秒とともに thread : : sleep 関数を呼び出すこと 
で、メッセージ間で停止します。 

メイン スレッドに おいて、最早 recv 関数を明示的に呼んではいません：代わりに、 rx をイテ レー 
夕として扱っています。受信した値それぞれを出力します。チャンネルが閉じられると、繰り返しも 
終わります。 

リスト 16-10 のコードを走らせると、各行の間に 1 秒の待機をしつつ、以下のような出力を目の当 
たりにするはずです： 

Got: hi 
Got: rrom 
Got: the 
Got : thread 

メインスレッドの for ループには停止したり、遅れせたりするコードは何もないので、メインス 
レッドが立ち上げたスレッドから値を受け取るのを待機していることがわかります。 


16.2.3 転送機をクローンして複数の生成器を作成する 

mpsc は、 mutiple producer, single consumer の頭字語であると前述しました。 mpsc を使用 
に移し、リスト 16-10 のコードを拡張して全てが値を同じ受信機に送信する複数のスレッドを生成し 
ましよう。チャンネルの転送の片割れをクローンすることでそうすることができます。リスト 16-11 
のようにですね： 

フアイル名： src / main.rs 

# use std :: thread ; 

# use std :: sync :: mpsc ; 
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# use std : : time : : Duration ; 

# 

# fn main () { 

// __ snip -- 

let ( tx , rx ) = mpsc :: channel (); 

let txl = mpsc : : Sender : : clone (& tx ); 

thread : : spawn (move || { 

let vaIs = vec ! [ 

Stri ng : : from (" hi ") , 

String : : from (" from ") , 

String : : f rom (" the ") , 

String : : f rom (" thread ") , 

]； 

for va L in va Is { 

txl . send ( val ). unwrap (); 

thread :: sleep (Du rati on : : from _ secs (1)); 

} 

})； 


thread: : spawn (move || { 

// 君のためにもっとメッセージを (more messages for you) 
let va Ls = vec! [ 

String: : from ("more ") ， 

Stri ng: : f rom(" messages 11 ) ， 

Stri ng: : f rom("for") , 

Stri ng: : f rom("you") , 


for val in vals { 

tx. send (val).unwrapO ; 

thread :: sleep (Du ration :: from_secs(1)); 


for received in rx { 

println! ("Got : {}" , received); 

} 

// --snip-- 
# } 


リスト 16-11: 複数の生成器から複数のメッセージを送信する 

今回、最初のスレッドを立ち上げる前に、チャンネルの送信側に対して clone を呼び出しています。 
これにより、最初に立ち上げたスレッドに渡せる新しい送信ハンドルが得られます。元のチャンネル 
の送信側は、2番目に立ち上げたスレッドに渡します。これにより2つスレッドが得られ、それぞれ 
チャンネルの受信側に異なるメッセージを送信します。 
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コードを実行すると、出力は以下のようなものになるはずです： 

Got : hi 
Got : more 
Got : rrom 
Got : messages 
Got : for 
Got : the 
Got : thread 
Got : you 

別の順番で値が出る可能性もあります；システム次第です。並行性が面白いと同時に難しい部分で 
もあります。異なるスレッドで色々な値を与えて thread: :sleep で実験をしたら、走らせるたびによ 
り非決定的になり、毎回異なる出力をするでしょう。 

チャンネルの動作方法を見たので、他の並行性に目を向けましょう。 

16.3 状態共有並行性 

メッセージ受け渡しは、並行性を扱う素晴らしい方法ですが、唯一の方法ではありません。 Go 言 
語ドキュメンテーションのスローガンのこの部分を再び考えてください：「メモリを共有することでや 
り取りする。」 

メモリを共有することでやり取りするとはどんな感じなのでしょうか？さらに、なぜメッセージ受 
け渡しに熱狂的な人は、それを使わず、代わりに全く反対のことをするのでしょうか？ 

ある意味では、どんなプログラミング言語のチャンネルも単独の所有権に類似しています。一旦 
チャンネルに値を転送したら、その値は最早使用することがないからです。メモリ共有並行性は、複 
数の所有権に似ています：複数のスレッドが同時に同じメモリ位置にアクセスできるのです。第15章 
でスマートボインタが複数の所有権を可能にするのを目の当たりにしたように、異なる所有者を管理 
する必要があるので、複数の所有権は複雑度を増させます。 Rust の型システムと所有権規則により、 
この管理を正当に行う大きな助けになります。例を挙げれば、メモリ共有を行うより一般的な並行性 
の基本型の 一つで あるミューテックスを見ましょう。 

16.3.1 ミューテックスを使用して一度に1つのスレッドからデータにアクセスす 
ることを許可する 

ミューテックスは、どんな時も1 つの スレッドにしかなんらかのデータへのアクセスを許可しない 
というように 、 ’’mutual exclusion ” (相互排他）の省略形です。ミューテックスにあるデータにアク 
セスするには、ミューテックスのロックを所望することでアクセスしたいことをまず、スレッドは通 
知しなければなりません。ロックとは、現在誰がデータへの排他的アクセスを行なっているかを追跡 
するミューテックの一部をなすデータ構造です。故に、ミューテックスはロックシステム経由で保持 
しているデータを死守する ( guarding ) と解説されます。 
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ミューテックスは、2つの規則を覚えておく必要があるため、難しいという評判があります： 

• データを使用する前にロックの獲得を試みなければならない。 

• ミューテックスが死守しているデータの使用が終わったら、他のスレッドがロックを獲得でき 
るように、データをアンロックしなければならない。 

ミューテックスを現実世界の物で例えるなら、マイクが1つしかない会議のパネルディスカッシヨ 
ンを思い浮かべてください。パネリストが発言できる前に、マイクを使用したいと申し出たり、通知 
しなければなりません。マイクを受け取ったら、話したいだけ話し、それから次に発言を申し出たパ 
ネリストにマイクを手渡します。パネリストが発言し終わった時に、マイクを手渡すのを忘れていた 
ら、誰も他の人は発言できません。共有されているマイクの管理がうまくいかなければ、パネルは予 
定通りに機能しないでしょう！ 

ミューテックスの管理は、正しく行うのに著しく巧妙なことがあるので、多くの人がチャンネルに 
熱狂的になるわけです。しかしながら、 Rust の型システムと所有権規則のおかげで、ロックとアン 
ロックをおかしくすることはありません。 

16.3.1.1 Mutex<T> の API 

ミューテックスの使用方法の例として、ミューテックスをシングルスレッドの文脈で使うことから 
始めましょう。リスト 16-12 のようにですね： 

フアイル名： src / main.rs 
use std :: sync :: Mutex ; 
fn mann () { 

let m = Mutex :: new (5); 

{ 

let mut num = m . lock () .unwrapO ; 

*num = 6; 

} 

println! ("m = {:?}", m ); 

} 

リスト 16-12： 簡潔性のために Mutex < T > の API をシングルスレッドの文脈で探究する 

多くの型同様、 new という関連関数を使用して Mutex < T > を生成します。ミューテックス内部のデー 
夕にアクセスするには 、 lock メソッドを使用してロックを獲得します。この呼び出しは、現在のス 
レッドをブロックするので、ロックを得られる順番が来るまで何も作業はできません。 

ロックを保持している他のスレッドがパニックしたら、 lock の呼び出しは失敗するでしょう。その 
場合、誰もロックを取得することは叶わないので、 unwrap すると決定し、そのような状況になった 
ら、このスレッドをパニックさせます。 
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ロックを獲得した後、今回の場合、 num と名付けられていますが、戻り値を中に入っているデータへ 
の可変参照として扱うことができます。型システムにより、 m の値を使用する前にロックを獲得して 
いることが確認されます： Mutex<i32> は i32 ではないので、 i32 を使用できるようにするには、ロッ 
クを獲得しなければならないのです。忘れることはあり得ません；型システムにより、それ以外の場 
合に内部の i32 にアクセスすることは許されません。 

疑っている可能性がありますが、 Mutex<T> はスマートポインタです。より正確を期すなら、 lock 
の呼び出しが MutexGuard というスマートポインタを返却します。このスマートポインタが、内部の 
データを指す Deref を実装しています；このスマートポインタはさらに MutexGuard がスコープを外 
れた時に、自動的にロックを解除する Drop 実装もしていて、これがリスト 16-12 の内部スコープ 
の終わりで発生します。結果として、ロックの解除が自動的に行われるので、ロックの解除を忘れ、 
ミューテックスが他のスレッドで使用されるのを阻害するリスクを負いません。 

ロックをドロップした後、ミューテックスの値を出力し、内部の i32 の値を 6 に変更できたことが 
確かめられるのです。 

16.3.1.2 複数のスレッド間で Mutex < T > を共有する 

さて、 Mutex<T> を使って複数のスレッド間で値を共有してみましょう。10個のスレッドを立ち上 
け'、各々カウンタの値を1ずつインクリメントさせるので、カウンタは0から10まで上がります。 
以下の数例は、コンパイルエラーになることに注意し、そのエラーを使用して Mutex<T> の使用法と、 
コンパイラがそれを正しく活用する手助けをしてくれる方法について学びます。リスト 16-13 が最初 
の例です： 

フアイル名： src / main.rs 

use std :: sync :: Mutex ; 
use std :: thread ; 

fn mann() { 

let counter = Mutex :: new(0); 
let mut handles = vec! []; 

for _ in 0••10 { 

let handle = thread: : spawn (move || { 

let mut num = counter. lock() .unwrapO; 

★num +=1; 

})； 

handles.push(handle); 

} 

for handle in handles { 

handle , join () .unwrapO ; 

} 

println! ("Result: {}" , ^counter. lock() .unwrapO); 
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} 

リスト 16-13： Mutex<T> により死守されているカウンタを10個のスレッドがそれぞれインクリメ 
ントする 

リスト 16-12 のように、 counter 変数を生成して Mutex<T> の内部に 132 を保持しています。次 
に、数値の範囲をマッピングして10個のスレッドを生成しています。 thread: :spawn を使用して、全 
スレッドに同じクロージャを与えています。このクロージャは、スレッド内にカウンタをムーブし、 
10 ck メソッドを呼ぶことで Mutex<T> のロックを獲得し、それからミユーテックスの値に1を足しま 
す。スレッドがクロージャを実行し終わったら、 num はスコープ外に出てロックを解除するので、他 
のスレッドが獲得できるわけです。 

メインスレッドで全ての join ハンドルを収集します。それからリスト 16-2 のように、各々に対し 
て join を呼び出し、全スレッドが終了するのを確かめています。その時点で、メインスレッドはロッ 
クを獲得し、このプログラムの結果を出力します。 

この例はコンパイルできないでしょうと仄めかしました。では、理由を探りましょう！ 

error[E0382] : capture of moved value : counter 

(エラー： ムーブされた値をキャプチャしています ：' counter') 

-- > src/main.rs :10:27 

Let handle = thread: : spawn(move || i 

- value moved (into closure) here 

let mut num = counter.lock().unwrap(); 

aaaaaaa value captured here after move 

=note : move occurs because 'counter' has type 'std: : sync: : Mutex<i32>', 
which does not implement the 'Copy' trait 

error[E0382]: use of moved value: 'counter' 

--> src/main.rs:21:29 

I 

9 | let handle = thread: : spawn(move || { 

| - value moved (into closure) here 

21 | println! ("Result: {}", ^counter.lock() .unwrapO); 

| aaaaaaa value used here after move 

I 

=note : move occurs because 'counter' has type 'std: : sync: : Mutex<i32>', 
which does not implement the 'Copy' trait 

error: aborting due to 2 previous errors 

(エラー： 前述の 2 つのエラーに より アボート） 

エラーメッセージは、 counter 値はクロージャにムーブされ、それから lock を呼び出したときに 
キャブチヤされていると述べています。その説明は、所望した動作のように聞こえますが、許可され 
ていないのです！ 


9 

10 
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プログラムを単純化してこれを理解しましょう。 for ループで 10 個スレッドを生成する代わりに、 
ループなしで 2 つのスレッドを作るだけにしてどうなるか確認しましょう。リスト 16-13 の最初の 
for ループを代わりにこのコードと置き換えてください： 

use std :: sync :: Mutex ; 
use std :: thread ; 

fn mann() { 

let counter = Mutex :: new(0); 
let mut handles = vec! []; 

let handle = thread :: spawn (move || { 

let mut num = counter. lock() .unwrapO; 

★num +=1; 

})； 

handles.push(handle); 

let handle2 = thread: : spawn (move || { 

let mut num2 = counter. lock() .unwrapO; 

*num2 +=1; 

})； 

handles.push(handle2); 

for handle in handles { 

handle. join() .unwrapO ; 

} 

println! ("Result: {}" , ^counter. lock() .unwrapO); 

} 

2 つのスレッドを生成し、 2 畨目のスレッドの変数名を handle2 と num2 に変更しています。今回こ 
のコードを走らせると、コンパイラは以下の出力をします： 

error[E0382] : capture of moved value : counter 
--> src/main.rs : 16 : 24 

I 

8 | let handle = thread: : spawn(move || { 

| - value moved (into closure) here 

16 | let mut num2 = counter.lock().unwrapO; 

| aaaaaaa value captured here after move 

I 

=note : move occurs because 'counter' has type 'std::sync::Mutex<i32>', 
which does not implement the 'Copy' trait 

error*[E0382] : use of moved value: 'counter' 

--> src/main.rs:26:29 

I 

8 | let handle = thread: : spawn(move || { 
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| - value moved (into closure) here 

26 | println! ("Result: {}"，^counter.lock() .unwrapO); 

| aaaaaaa value used here after move 

I 

=note : move occurs because 'counter' has type 'std::sync::Mutex<i32>' ， 
which does not implement the 'Copy' trait 

error: aborting due to 2 previous errors 


なるほど！最初のエラーメッセージは、 handle に紐づけられたスレッドのクロージャに counter 
がムーブされていることを示唆しています。そのムーブにより、それに対して lock を呼び出し、結 
果を 2 杳目のスレッドの num2 に保持しようとした時に、 counter をキャプチャすることを妨げてい 
ます！ゆえに、コンパイラは、 counter の所有権を複数のスレッドに移すことはできないと教えてく 
れています。これは、以前では確認しづらかったことです。なぜなら、スレッドはループの中にあり、 
ループの違う繰り返しにある違うスレッドをコンパイラは指し示せないからです。第15章で議論し 
た複数所有権メソッドによりコンパイルエラーを修正しましょう。 


16.3.1.3 複数のスレッドで複数の所有権 

第15章で、スマートポインタの Rc<T> を使用して参照カウントの値を作ることで、1つの値に複 
数の所有者を与えました。同じことをここでもして、どうなるか見ましょう。リスト 16-14 で Rc<T> 
に Mutex<T> を包含し、所有権をスレッドに移す前に Rc<T> をクローンします。今やエラーを確認し 
たので、 for ループの使用に立ち戻り、クロージャに move キーワードを使用し続けます。 


フアイル名： src / mam.rs 


use std :: rc :: Rc; 
use std :: svnc :: Mutex ; 
use std :: thread ; 


fn mann() i 

let counter = Rc :: new (Mutex :: new(0)); 
let mut handles = vec! []; 


for _ in 0.•10 { 

let counter = Rc: : clone(&counter); 
let handle = thread :: spawn (move || { 

let mut num = counter. lock() .unwrapO; 


★num +=1; 

})； 

handles.push(handle); 


for handle in handles { 

handle. join().unwrapO ; 

} 
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pnntln ! (" Result : {}"， 〇 - counter . lock () . unwrapO ); 

} 

リスト 16-14： Rc < T > を使用して複数のスレッドに Mutex く T > を所有させようとする 

再三、コンパイルし……別のエラーが出ました！コンパイラはいろんなことを教えてくれてい 
ます。 


error[E0277] : the trait bound std :: rc :: Rc<std :: sync :: Mutex<i32>> : 
std :: marker :: Sena is not satisfied in [cLosure@src/main.rs: 11 :36: 

15:10 counter:std :: re : :Rc<std :: sync : :Mutex<i32>>] 

( エラー：トレイト境界 ' std :: re : : Rc<std : : sync : : Mutex<i32>> : 

std :: marker :: Sena t ま ' [closure@src/main.rs :11:36:15:10 

counter : std :: re : : Rc く std : : sync : : Mutex<i32>>] ' で満たされていません） 

-- > src/main.rs :11:22 

I 

11 | let handle = thread :: spawrumove 丨丨 i 

| aaaaaaaaaaaaa 'std :: rc : :Rc<std :: sync :: Mutex<i32>>' 

cannot be sent between threads sarely 

(' std : : rc : : Rc<std: :sync : : Mutex<i32>> ' は、スレッド間で 
安全に送信できません） 

I 

= help : within '[ closure @ src / main . rs : ll :36: 15 : 10 
counter : sta :: rc :: Rc < std :: sync :: Mutex < i 32 >>」 ， the trait ' std : : marker: : Send is 
not implemented for ' std :: rc : : Rc < std :: sync :: Mutex < i 32>>' 

( ヘルプ ： ' [closure@src/main. rs: 11:36 15:10 

counter: std :: rc : : Rc<std : : sync : : Mutex <i32>>] '内でトレイト ' std : : marker : : Send' 

は、 

' std :: rc : : Rc く std : : sync : : Mutex<i32>>' に対して実装されていません） 

= note : required because it appears within the type 
'[closure@src/main.rs:11:36:15 : 10 counter:std :: rc :: Rc<std :: sync: : Mutex<i32>>]' 
( 注釈：型 ' [cl_osure@src/main. rs: 11:3615:10 

counter : std :: rc : : Rc く std : : sync : : Mutex<i32>>] ' 内に出現するので必要です） 

= note : required by std :: thread :: spawn 

( 注釈： ' std : : thread : : spawn' により必要とされています） 

おお、このエラーメッセージはとても長ったらしいですね！こちらが、注目すべき重要な部分で 
す：最初のインラインエラーは' std: : rc: : Rc<std: : sync: : Mutex<i32>> cannot be sent between 
threads safely と述べています。この理由は、エラーメッセージの次に注目すべき重要な部分にあ 
ります 0 洗練されたエラーメッセージは、 the trait bound 'Send' is not satisfied と述べていま 
す。 Send については、次の節で語ります：スレッドとともに使用している型が並行な場面で使われる 
ことを意図したものであることを保証するトレイトの1つです。 

残念ながら、 Rc<T> はスレッド間で共有するには安全ではないのです。 Rc<T> が参照カウントを管 
理する際、 clone が呼び出されるたびにカウントを追加し、クローンがドロップされるたびにカウン 
卜を差し引きます。しかし、並行基本型を使用してカウントの変更が別のスレッドに妨害されないこ 
とを確認していないのです。これは間違ったカウントにつながる可能性があり、今度はメモリリーク 
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や、使用し終わる前に値がドロップされることにつながる可能性のある潜在的なバグです。必要なの 
は、いかにも Rc<T> のようだけれども、参照カウントへの変更をスレッドセーフに行うものです。 

16.3.1.4 Arc < T > で 原子的な 参照 カウント 

幸いなことに、 a 「 c < t > は rc < t > のような並行な状況で安全に使用できる型です。 a は atomic を 
表し、原子的に参照カウントする型を意味します。アトミックは、ここでは詳しく講義しない並行性 
の別の基本型です：詳細は、 std :: sync: : atomic の標準ライブラリドキュメンテーションを参照され 
たし。現時点では、アトミックは、基本型のように動くけれども、スレッド間で共有しても安全なこ 
とだけ知っていれば良いです。 

そうしたらあなたは、なぜ全ての基本型がアトミックでなく、標準ライブラリの型も標準で Arc<T> 
を使って実装されていないのか疑問に思う可能性があります。その理由は、スレッド安全性が、本当 
に必要な時だけ支払いたい パフォーマンスの 犠牲とともに得られるものだからです。 シングルス レッ 
ドで値に処理を施すだけなら、アトミックが提供する保証を強制する必要がない方がコードはより速 
く走るのです。 

例に回帰しましょう： Arc<T> と Rc<T> の API は同じなので、 use 行と new の呼び出しと clone の 
呼び出しを変更して、プログラムを修正します。リスト 16-15 は、ようやく コンパイル でき、動作し 
ます： 

フアイル名： src / main.rs 

use std :: sync :: {Mutex ， Arc} ; 
use std :: thread ; 

fn mann() { 

let counter = Arc: :new (Mutex: : new(0)); 
let mut handles = vec! []; 

for _ in 0••10 { 

let counter = Arc: : clone(&counter); 
let handle = thread: : spawn (move || { 

let mut num = counter. lock() .unwrapO; 

★num +=1; 

})； 

handles.push(handle); 

} 

for handle in handles { 

handle, join() .unwrapO ; 

} 

println! ("Result: {}" , ^counter. lock() .unwrapO); 

} 


リスト 16-15: Arc < T > を使用して Mutex < T > をラップし、所有権を複数の スレッド 間で共有できる 
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ようにする 

このコードは、以下のように出力します： 

Result :10 

やりました！ 0から10まで数え上げました。これは、あまり印象的ではないように思えるかもし 
れませんが、本当に Mutex<T> とスレッド安全性に ついて いろんなことを教えてくれました。このプ 
ログ ラムの構造を使用して、カウンタをインクリメントする以上の複雑な処理を行うこともできるで 
しょう。この手法を使えば、計算を独立した部分に小分けにし、その部分をスレッドに分割し、それ 
から Mutex<T> を使用して、各スレッドに最終結果を更新させることができます。 

16.3.2 RefCell く T >/ Rc く T > と Mutex < T >/ Arc く T > の類似性 

counter は不変なのに、その内部にある値への可変参照を得ることができたことに気付いたでしょ 
うか；つまり、 Mutex<T> は、 Cell 系のように内部可変性を提供するわけです。第15章で RefCelA く T> 
を使用して Rc<T> の内容を可変化できるようにしたのと同様に、 Mutex<T> を使用して Arc<T> の内容 
を可変化しているのです。 

気付いておくべき別の詳細は、 Mutex<T> を使用する際にあらゆる種類のロジックエラーからは、コ 
ンパイラは保護してくれないということです。第15章で Rc<T> は、循環参照を生成してしまうリス 
クを伴い、そうすると、2つの Rc<T> の値がお互いを参照し合い、メモリリークを引き起こしてしまう 
ことを思い出してください。同様に、 Mutex<T> はデッドロックを生成するリスクを伴っています。こ 
れは、処理が2つのリソースをロックする必要があり、2つのスレッドがそれぞれにロックを1つ獲 
得して永久にお互いを待ちあってしまうときに起こります。デッドロックに興味があるのなら、デッ 
ドロックのある Rust プログラムを組んでみてください；それからどんな言語でもいいので、ミユー 
テックスに対してデッドロックを緩和する方法を調べて、 Rust で是非、それを実装してみてくださ 
い。 Mutex<T> と MutexGuard に関する標準ライブラリの API ドキユメンテーシヨンは、役に立つ情報 
を提供してくれます。 

Send と Sync トレイトと、それらを独自の型で使用する方法について語って、この章を締めく くり 
ます。 


16.4 Sync と Send トレイトで拡張可能な並行性 

面白いことに、 Rust 言語には、寡少な並行性機能があります。この章でここまでに語った並行性機 
能のほとんどは、標準ライブラリの一部であり、言語ではありません。並行性を扱う選択肢は、言語 
や標準ライブラリに制限されません；独自の並行性機能を書いたり、他人が書いたものを利用したり 
できるのです。 

ですが、 2 つの並行性概念が言語に埋め込まれています： std : : marker トレイトの Sync と Send 
です。 



第 16 章恐れるな！並行性 


400 


16.4.1 Send でスレッド間の所有権の転送を許可する 

Send マーカートレイトは、 Send を実装した型の所有権をスレッド間で転送できることを示唆しま 
す。 Rust のほとんどの型は Send ですが、 Rc<T> を含めて一部例外があります：この型は、 Rc<T> の値 
をクローンし、クローンしたものの所有権を別のスレッドに転送しようとしたら、両方のスレッドが 
同時に参照カウントを更新できてしまうので、 Send になり得ません。このため、 Rc<T> はスレッド安 
全性のためのパフォーマンスの犠牲を支払わなくても済む、シングルスレッド環境で使用するために 
実装されているわけです。 

故に、 Rust の型システムとトレイト境界により、 Rc<T> の値を不安全にスレッド間で誤って送信す 
ることが絶対ないよう保証してくれるのです。リスト 16-14 でこれを試みた時には、 the trait Send 
is not implemented for Rc<Mutex<i32>> という エラ ーが出ました。 Send の Arc く T> に切り替えた 
ら、コードはコンパイルできたわけです。 

完全に Send の型からなる型も全て自動的に Send と印付けされます。生ポインタを除くほとんどの 
基本型も Send で、生ボインタについては第19章で議論します。 

16.4.2 Sync で複数のスレッドからのアクセスを許可する 

Sync マーカートレイトは、 Sync を実装した型は、複数のスレッドから参照されても安全であるこ 
とを示唆します0言い換えると、 &T (丁への 参照）が Send なら、型 T は Sync であり、参照が他のス 
レッドに安全に送信できることを意味します 0 Send 同様、基本型は Sync であり、 Sync の型からのみ 
構成される型もまた Sync です。 

Send ではなかったのと同じ理由で、 スマート ポインタの Rc<T> もまた Sync ではありません。 
RefCelA<T> 型（これについては第15章で話しました）と関連する Cell く T> 系についても Sync ではあ 
りません。 RefCeU<T> が実行時に行う借用チヱックの実装は、 スレッド 安全ではないのです。 スマー 
ト ポインタの Mutex<T> は Sync で、「複数の スレッド 間で Mutex<T> を共有する」節で見たように、複 
数の スレッドで アクセスを共有するのに使用することができます。 

16.4.3 Send と Sync を手動で実装するのは非安全である 

Send と Sync トレイトから構成される型は自動的に Send と Sync にもなるので、それらのトレイト 
を手動で実装する必要はありません。マーカートレイトとして、実装すべきメソッドさえも何もあり 
ません。並行性に関連する不変条件を強制することに役立つだけなのです。 

これらのトレイトを手動で実装するには、 unsafe な Rust コードを実装することが関わってきま 
す。 unsafe な Rust コードを使用することについては第19章で語ります；とりあえず、重要な情報 
は、 Send と Sync ではない部品からなる新しい並行な型を構成するには、安全性保証を保持するため 
に、注意深い思考が必要になるということです。 The Rustonomicon には、これらの保証とそれを 
保持する方法についての情報がより多くあります。 
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16.5 まとめ 

この本において並行性を見かけるのは、これで最後ではありません：第20章のプロジヱクトでは、 
この章の概念をここで議論した微小な例よりもより現実的な場面で使用するでしょう。 

前述のように、 Rust が並行性を扱うごく一部が言語の一部なので、多くの並行性解決策は、クレー 
卜として実装されています。これらは標準ライブラリよりも迅速に進化するので、確実にオンライン 
でマルチスレッド環境で使用すべき現在の最先端のクレートを検索してください。 

Rust の標準ライブラリは、メッセージ受け渡しにチャンネルを、並行の文脈で安全に使用できる、 
Mutex<T> や Arc<T> などのスマートポインタ型を提供しています。型システムと借用チェッカーによ 
り、これらの解決策を使用するコードがデータ競合や無効な参照に行き着かないことを保証してくれ 
ます。一旦コードをコンパイルすることができたら、他の言語ではありふれている追跡困難な類のバ 
グなしに、複数のスレッドでも喜んで動くので安心できます。並行プログラミングは、もはや恐れる 
べき概念ではありません：進んでそして、恐れずにプログラムを並行にしてください！ 

次は、 Rust プログラムが肥大化するにつれて問題をモデル化し、解決策を構造化する慣例的な方法 
について話します。さらに、 Rust のイディオムがオブジェクト指向プログラミングで馴染み深いかも 
しれないイディオムに関連する方法についても議論します。 
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17； 


Rust のオブジェクト指向プログラミン 
グ機能 


オブジェクト指向プログラミング （ OOP ) は、プログラムをモデル化する手段です。オブジェクト 
は、1960年代の Simula に端緒を発しています。このオブジェクトは、お互いにメッセージを渡し 
合うというアラン•ケイ (Alan Kay ) のプログラミングアーキテクチャに影響を及ぼしました。彼は、 
このアーキテクチャを解説するために、オブジェクト指向プログラミングという用語を造語しました。 
多くの競合する定義が OOP が何かを解説しています； Rust をオブジェクト指向と区分する定義もあ 
りますし、しない定義もあります。この章では、広くオブジェクト指向と捉えられる特定の特徴と、 
それらの特徴がこなれた Rust でどう表現されるかを探究します。それからオブジェクト指向のデザ 
インパターンを Rust で実装する方法を示し、そうすることと Rust の強みを活用して代わりの解決 
策を実装する方法の代償を議論します。 

17.1 オブジェクト指向言語の特徴 

言語がオブジェクト指向と考えられるのになければならない機能に ついて、 プログラミングコミュ 
ニティ内での総意はありません。 Rust は OOP を含めた多くのプログラミングパラダイムに影響を受 
けています；例えば、第13章で関数型プログラミングに由来する機能を探究しました。議論はあるか 
もしれませんが、0 OP 言語は特定の一般的な特徴を共有しています。具体的には、オブジェクトや力 
プセル化、継承などです。それらの個々の特徴が意味するものと Rust がサポートしているかを見ま 
しょう。 

17.1.1 オブジェクトは、データと振る舞いを含む 

エーリヒ.ガンマ (Enoch Gamma )、 リチャード-ヘルム （Richard Helm )、 ラルフ•ジョンソン 
(Ralph Johnson )、 ジョン.ブリシディース （John Vlissides ) (アディソン-ワズリー. プロ） により、 
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1994年に書かれたデザインパターン：再利用可能なオブジェクト指向ソフトウェアの要素という本 
は、俗に4人のギャングの本（訳注 ： the Gang of Four book ; GoF とよく略される）と呼ばれ、オブ 
ジェクト指向デザインパターンのカタログです。そこでは、 OOP は以下のように定義されています： 

オブジェクト指向プログラムは、オブジェクトで構成される。オブジェクトは、データとその 
データを処理するプロシージャを梱包している。このプロシージャは、典型的にメソッドまた 
はオペレーシヨンと呼ばれる。 

この定義を使用すれば、 Rust はオブジェクト指向です：構造体と enum にはデータがありますし、 
impi ブロックが構造体と enum にメソッドを提供します。メソッドのある構造体と enum は、オブ 
ジェクトとは呼ばれないものの、 GoF のオブジェクト定義によると、同じ機能を提供します。 

17.1.2 カプセル化は、実装詳細を隠蔽する 

0 0 P とよく紐づけられる別の側面は、カプセル化の思想です。これは、オブジェクトの実装詳細 
は、そのオブジェクトを使用するコードにはアクセスできないことを意味します。故に、オブジェク 
卜と相互作用する唯一の手段は、その公開 API を通してです；オブジェクトを使用するコードは、才 
ブジヱクトの内部に到達して、データや振る舞いを直接変更できるべきではありません。このため 
に、プログラマはオブジェクトの内部をオブジェクトを使用するコードを変更する必要なく、変更し 
リファクタリングできます。 

カプセル化を制御する方法は、第7章で議論しました： pub キーワードを使用して、自分のコー 
ドのどのモジュールや型、関数、メソッドを公開するか決められ、規定ではそれ以外のものは全て 
非公開になります。例えば、 i32 値のベクタを含むフィールドのある AveragedCollection という構 
造体を定義できます。この構造体はさらに、ベクタの値の平均を含むフィールドを持てます。つま 
り、平均は誰かが必要とする度に、オンデマンドで計算する必要はないということです。言い換え 
れば、 AveragedColAection は、計算した平均をキャッシュしてくれるわけです。リスト 17-1 には、 
AveragedCoVLecti on 構造体の定義があります： 

ファイル名： src / lib.rs 


pub struct AveragedCoilection { 
list: Vec<i32> , 
average : f64, 

} 

リスト 17-1: 整数のリストと コレクション の要素の平均を管理する AveragedCollection 構造体 

構造体は、他のコードが使用できるように pub で印づけされていますが、構造体のフィールドは非 
公開のままです。値が追加されたりリストから削除される度に、平均も更新されることを保証したい 
ので、今回の場合重要です。 add や remove 、 average メソッドを構造体に実装することでこれをしま 
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す。リスト 17-2 のようにですね: 
ファイル名： src / lib.rs 


# pub struct AveragedCollection { 

# list: Vec<i32>, 

# average : f64, 

# } 

impl AveragedCollection { 

pub fn add (&mut self, value : i32) { 
self .list.push(value); 
self .update_average(); 

} 

pub fn remove (&mut self) -> 0ption<i32> { 
let result = self .list.pop(); 
match result { 

Some(value) => { 

self .update_average(); 
Some(value) 

}, 

None => None, 



pub fn average (& self ) -> f 64 { 
self .average 

} 

fn update _ average(&mut self ) { 

let total : 1.32 = self . list . iter () . sum (); 

self .average = total as f 64 / self . list . len () as f 64; 



リスト 17-2: AveragedCollecti on の add 、 remove 、 average 公開メソッドの実装 

add 、 remove 、 average の公開メソッドが AveragedCollection のインスタンスを変更する唯一の 
方法になります。要素が add メソッドを使用して list に追加されたり 、 remove メソッドを使用して 
削除されたりすると、各メソッドの実装が average フィールドの更新を扱う非公開の update_average 
メソッドも呼び出します。 

list と average フィールドを非公開のままにしているので、外部コードが要素を list フィールド 
に直接追加したり削除したりする方法はありません；そうでなければ、 average フィールドは 、 list 
が変更された時に同期されなくなる可能性があります 。 average メソッドは average フィールドの値 
を返し、外部コードに average を読ませるものの、変更は許可しません。 

構造体 AveragedCollection の実装詳細をカプセル化したので、データ構造などの側面を将来容 
易に変更することができます。例を挙げれば、 list フィールドに Vec < i 32> ではなく HashSet < i 32 
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>を使うこともできます。 add 、 remove 、 average 公開メソッドのシグニチヤが同じである限り、 
AveragedCoVLection を使用するコードは変更する必要がないでしょう。代わりに list を公開にした 
ら、必ずしもこうはならないでしょう： HashSet < i 32> と Vec < i 32> は、要素の追加と削除に異なるメ 
ソッドを持っているので、外部コードが直接 list を変更しているなら、外部コードも変更しなけれ 
ばならない可能性が高いでしょう。 

カプセル化が、言語がオブジェクト指向と考えられるのに必要な側面ならば、 Rust はその条件を満 
たしています。コードの異なる部分で pub を使用するかしないかという選択肢のおかげで、実装詳細 
をカプセル化することが可能になります。 

17.1.3 型システム、およびコード共有としての継承 

継承は、それによってオブジェクトが他のオブジェクトの定義から受け継ぐことができる機構であ 
り、それ故に、再定義する必要なく、親オブジェクトのデータと振る舞いを得ます。 

言語がオブジェクト指向言語であるために継承がなければならないのならば、 Rust は違います。 
親構造体のフィールドとメソッドの実装を受け継ぐ構造体を定義する方法はありません。しかしなが 
ら、継承がプログラミング道具箱にあることに慣れていれば、そもそも継承に手を伸ばす理由によっ 
て、 Rust で他の解決策を使用することができます。 

継承を選択する理由は主に2つあります。1つ目は、コードの再利用です：ある型に特定の振る舞い 
を実装し、継承により、その実装を他の型にも再利用できるわけです。デフォルトのトレイトメソッ 
ド実装を代わりに使用して、 Rust コードを共有でき、これは、リスト 10-14 で Summary トレイトに 
summarize メソッドのデフォルト実装を追加した時に見かけました。 Summary トレイトを実装する型 
は全て、追加のコードなく summarize メソッドが使用できます。これは、親クラスにメソッドの実装 
があり、継承した子クラスにもそのメソッドの実装があることと似ています。また、 Summary トレイ 
卜を実装する時に 、 summarize メソッドのデフォルト実装を上書きすることもでき、これは、親クラ 
スから継承したメソッドの実装を子クラスが上書きすることに似ています。 

継承を使用するもう1つの理由は、型システムに関連しています：親の型と同じ箇所で子供の型を 
使用できるようにです。これは、 多相性 （ polymorphism ) とも呼ばれ、複数のオブジェクトが特定 
の特徴を共有しているなら、実行時にお互いに代用できることを意味します。 

17.1 .4 多相性 

多くの人にとって、多相性は、継承の同義語です。ですが、実際には複数の型のデータを取り 
扱えるコードを指すより一般的な概念です。継承について言えば、それらの型は一般的にはサ 
ブクラスです。 

Rust は代わりにジヱネリクスを使用して様々な可能性のある型を抽象化し、トレイト境界を 
使用してそれらの型が提供するものに制約を課します。これは時に、 パラメータ境界 多 相性 
(bounded parametric polymorphism ) と呼ばれます。 
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継承は、近年、多くのプログラミング言語において、プログラムの設計解決策としては軽んじられ 
ています。というのも、しばしば必要以上にコードを共有してしまう危険性があるからです。サブク 
ラスは、必ずしも親クラスの特徴を全て共有するべきではないのに、継承ではそうなってしまうので 
す。これにより、プログラムの設計の柔軟性を失わせることもあります。また道理に合わなかったり、 
メソッドがサブクラスには適用されないために、エラーを発生させるサブクラスのメソッドの呼び出 
しを引き起こす可能性が出てくるのです。さらに、サブクラスに1つのクラスからだけ継承させる言 
語もあり、さらにプログラムの設計の柔軟性が制限されます。 

これらの理由により、継承ではなくトレイトオブジェクトを使用して Rust は異なるアプローチを 
取っています。 Rust において、トレイトオブジェクトがどう多相性を可能にするかを見ましょう。 

17.2 トレイトオブジェクトで異なる型の値を許容する 

第8章で、ベクタの1つの制限は、たった1つの型の要素を保持することしかできないことだと述 
ベました。リスト 8-10 で整数、浮動小数点数、テキストを保持する列挙子のある SpreadsheetCeVL 
enum を定義して、これを回避しました。つまり、各セルに異なる型のデータを格納しつつ、 1 行の 
セルを表すべクタを保持するということです。 コンパイル 時にわかるある固定されたセットの型にし 
か取り替え可能な要素がならない場合には、完璧な解決策です。 

ところが、時として、ライブラリの使用者が特定の場面で合法になる型のセットを拡張できるよう 
にしたくなることがあります。これをどう実現する可能性があるか示すために、各アイテムに draw 
メソッドを呼び出してスクリーンに描画するという、 GUI ツールで一般的なテクニックをしてあるリ 
ストの要素を走査する例の GUI ツールを作ります。 GUI ライブラリの構造を含む grn ' と呼ばれるラ 
イブラリクレートを作成します。このクレートには、他人が使用できる Button や Text Field などの 
型が包含される可能性があります。さらに、 gm ' の使用者は、描画可能な独自の型を作成したくなる 
でしょう：例えば、ある人は Image を追加し、別の人は SelectBox を追加する可能性があります。 

この 例のために本格的な GUI ライブラリは実装するつもりはありませんが、部品がどう組み合わ 
さるかは示します。ライブラリの記述時点では、他のプログラマが作成したくなる可能性のある型全 
てを知る由も、定義することもできません。しかし、 gm •は異なる型の多くの値を追いかけ、 この 異な 
る型の値に対して draw メソッドを呼び出す必要があることは、確かにわかっています 。 draw メソッ 
ドを呼び出した時に正確に何が起きるかを知っている必要はありません。値にそのメソッドが呼び出 
せるようあることだけわかっていればいいのです。 

継承のある言語でこれを行うには、 draw という名前のメソッドがある Component というクラスを 
定義する可能性があります。 Button 、 Image 、 SelectBox などの他のクラスは、 Component を継承し、 
故に draw メソッドを継承します。個々に draw メソッドをオーバーライドして、独自の振る舞いを定 
義するものの、フレームワークは、 Component インスタンスであるかのようにその型全部を扱い、こ 
の型に対して draw を呼び出します。ですが、 Rust に継承は存在しないので、使用者に新しい型で拡 
張してもらうために gm ' ライブラリを構成する他の方法が必要です。 
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17.2.1 一般的な振る舞いにトレイトを定義する 

gui に欲しい振る舞いを実装するには、 draw という1つのメソッドを持つ Draw というトレイトを 
定義します。それからトレイトオブジェクトを取るベクタを定義できます。トレイトオブジェクト 
は、指定したトレイトを実装するある型のインスタンスを指します。&参照や Box < T > スマートポイン 
夕などの、何らかのポインタを指定し、それから関係のあるトレイトを指定する（トレイトオブジェ 
クトがポインタを使用しなければならない理由については、第 19 章の「動的サイズ付け型と Sized 
トレイト」節で語ります）ことでトレイトオブジェクトを作成します。ジヱネリックまたは具体的な 
型があるところにトレイトオブジェクトは使用できます。どこでトレイトオブジェクトを使用しよう 
と、 Rust の型システムは、コンパイル時にその文脈で使用されているあらゆる値がそのトレイトオブ 
ジェタトのトレイトを実装していることを保証します。結果的にコンパイル時に可能性のある型を全 
て知る必要はなくなるのです。 

Rust では、構造体と enum を他の言語のオブジェクトと区別するために「オブジェクト」と呼ぶ 
ことを避けていることに触れましたね。構造体や enum において、構造体のフィールドのデータや 
impl ブロックの振る舞いは区分けされているものの、他の言語では1つの概念に押し込められるデー 
夕と振る舞いは、しばしばオブジェクトと分類されます。しかしながら、トレイトオブジェクトは、 
データと振る舞いをごちゃ混ぜにするという観点で他の言語のオブジェクトに近いです。しかし、卜 
レイトオブジェクトは、データを追加できないという点で伝統的なオブジェクトと異なっています。 
トレイトオブジェクトは、他の言語のオブジェクトほど一般的に有用ではありません：その特定の目 
的は、共通の振る舞いに対して抽象化を行うことです。 

リスト 17-3 は、 draw という 1 つのメソッドを持つ Draw というトレイトを定義する方法を示して 
います： 

ファイル名： src / lib.rs 


pub trait Draw { 

fn draw (& self ); 

} 

リスト 17-3: Draw トレイトの定義 

この記法は、第10章のトレイトの定義方法に関する議論で馴染み深いはずです。その次は、新し 
い記法です：リスト 17-4 では、 components というべクタを保持する Screen という名前の構造体を定 
義しています。このべクタの型は Box く Draw 〉 で、これはトレイトオブジェクトです； Draw トレイトを 
実装する Box 内部の任意の型に対する代役です。 

ファイル名： src / lib.rs 


# pub trait Draw { 
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# fn draw(&self) ; 

# } 

# 

oub struct Screen i 

pub components: Vec<Box<Draw>> , 

} 

リスト 17-4: Draw トレイトを実装するトレイトオブジェクトのベクタを保持する components 
フィールドがある Screen 構造体の定義 

Screen 構造体に、 components の各要素に対して draw メソッドを呼び出す r*un というメソッドを 
定義します。リスト 17-5 のようにですね： 

ファイル名： src / lib.rs 

# pub trait Draw { 

# fn draw(&self) ; 

# } 

# 

# pub struct Screen { 

# pub components : Vec<Box<Draw>> , 

# } 

# 

impl Screen { 

pub fn run (&self ) { 

for component in self .components.iter() { 
component.draw(); 

} 

} 

} 

リスト 17-5: 各コンポーネントに対して draw メソッドを呼び出す Screen の run メソッド 

これは、トレイト境界を含むジェネリックな型引数を使用する構造体を定義するのとは異なる動作 
をします。ジェネリックな型引数は、一度に1つの具体型にしか置き換えられないのに対して、トレ 
イトオブジェクトは、実行時にトレイトオブジェクトに対して複数の具体型で埋めることができます。 
例として、ジェネリックな型とトレイト境界を使用してリスト 17-6 のように Screen 構造体を定義す 
ることもできました： 

ファイル名： src / lib.rs 


# pub trait Draw { 

# fn draw(&self) ; 

# } 

# 

pub struct Screen く T: Draw 〉 { 
pub components: Vec<T> , 
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impl < T > Screen く T > 
wnere T : Draw { 
pub fn run (& self ) { 

for component in self . components . iter () { 
component . draw (); 



リスト 17-6: ジヱネリクスとトレイト境界を使用した Screen 構造体と run メソッドの対立的な 
実装 

こうすると、全てのコンポーネントの型が Button だったり、 TextField だったりする Screen のイ 
ンスタンスに制限されてしまいます。絶対に同種のコレクションしか持つ予定がないのなら、ジェネ 
リクスとトレイト境界は、定義がコンパイル時に具体的な型を使用するように単相化されるので、望 
ましいです。 

~■方で、メソッドがトレイトオブジェクトを使用すると、1つの Screen インスタンスが、 Box く 
Button 〉 と Box < TextField > を含む Vec < T > を保持できます 0 この動作方法を見、それから実行時性能 
の裏の意味について語りましょう。 


17.2.2 トレイトを実装する 

さて、 Draw トレイトを実装する型を追加しましょう。 Button 型を提供します。ここも、実際に GUI 
ライブラリを実装することは、この本の範疇を超えているので、 draw メソッドの本体は、何も有用 
な実装はしません。実装がどんな感じになるか想像するために、 Button 構造体は、 width 、 height 、 
label フィールドを持っている可能性があります。リスト 17-7 に示したようにですね： 

ファイル名： src / lib.rs 


# pub trait Draw { 

# fn draw (& self ) ; 

# } 

林 

pub struct Button { 
pub width : u 32, 
pub height : u 32 , 
pub label : String , 

} 

impl Draw for Button { 
fn draw (& self ) { 

// code to actually draw a button 

// 実際にボタンを描画するコード 

} 
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} 

リスト 17-7: Draw トレイトを実装するある Button 構造体 

Button の width 、 height 、 label フィールドは、 TextField 型のように、それらのフィールドプ 
ラス placeholder フィールドを代わりに持つ可能性のある他のコンポーネントのフィールドとは異な 
るでしょう。スクリーンに描画したい型のコンポーネントはそれぞれ Draw トレイトを実装しますが、 
Button がここでしているように 、 draw メソッドでは異なるコードを使用してその特定の型を描画す 
る方法を定義しています（実際の GUI コードは、この章の範疇を超えるのでありませんが)。例えば、 
Button には、ユーザがボタンをクリックした時に起こることに関連するメソッドを含む、追加の impl 
ブロックがある可能性があります。この種のメソッドは、 TextField のような型には適用されません。 

ライブラリの使用者が、 width 、 height 、 options フィールドのある SelectBox 構造体を実装しよ 
うと決めたら、 SelectBox 型にも Draw トレイトを実装します。リスト 17-8 のようにですね： 

フアイル名： src/main.rs 

extern crate gui ; 

use gui :: Draw ; 

struct SelectBox { 
width : u 32 , 
height : u 32 , 
options : Vec < String > , 

} 


impl Draw for SelectBox { 
fn draw (& self ) { 

// code to actually draw a select box 
// セレクトボックスを実際に描画するコード 



リスト 17-8: gui を使用し、 SelectBox 構造体に Draw トレイトを実装する別のクレート 

ライブラリの使用者はもう、 main 関数を書き、 Screen インスタンスを生成できます。 Screen イン 
スタンスには、それぞれを Box く T > に放り込んでトレイトオブジェクト化して SelectBox と Button を 
追加できます。それから Screen インスタンスに対して run メソッドを呼び出すことができ、そうす 
ると各コンポーネントの draw が呼び出されます。リスト 17-9 は、この実装を示しています： 

フアイル名： src/main.rs 

use gun :: { Screen , Button } ; 

fn mann () { 

let screen = Screen { 
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components : vec ! [ 

Box : : new(SelectBox { 
width : 75, 
height :10, 
options : vec ! [ 

// はい 

String : : f rom (" Yes ") , 

// 多分 

String : : f rom (" Maybe ") , 

"いいえ 

String : : f rom (" No ") 

], 

}), 

Box :: new(Button { 
width : 50, 
height :10, 

//了解 

label : String : : from (" OK ") , 

})， 

], 

}； 


screen . run (); 

} 

リスト 17-9: トレイトオブジェクトを使って同じトレイトを実装する異なる型の値を格納する 

ライブラリを記述した時点では、誰かが SelectBox 型を追加する可能性があるなんて知りませんで 
したが、 Screen の実装は、新しい型を処理し、描画することができました。何故なら、 SelectBox は 
Draw 型、つまり、 draw メソッドを実装しているからです。 

この値の具体的な型ではなく、値が応答したメッセージにのみ関係するという概念は、動的型付け 
言語のダックタイピングに似た概念です：アヒルのように歩き、鳴くならば、アヒルに違いないので 
す！リスト 17-5 の Screen の run の実装では、 run は、各コンポーネントの実際の型がなんであるか 
知る必要はありません。コンポーネントが、 Button や Select Box のインスタンスであるかを確認する 
ことはなく、コンポーネントの draw メソッドを呼び出すだけです。 components べクタで Box < Draw > 
を値の型として指定することで、 Screen を、 draw メソッドを呼び出せる値を必要とするように定義 
できたのです。 


17.2.2.1 注釈：ダックタイピング について 

ご存知かもしれませんが、ダックタイピングについて補足です。ダックタイピングとは、動的 
型付け言語や C ++ のテンプレートで使用される、特定のフィールドやメソッドがあることを 
想定してコンパイルを行い、実行時に実際にあることを確かめるというプログラミング手法で 
す。ダック • テストという思考法に由来するそうです。 

ダックタイビングの利点は、 XML や JSON など、厳密なスキーマがないことが多い形式を扱 
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いやすくなること、欠点は、実行してみるまで動くかどうかわからないことでしょう。 

トレイトオブジェクトと Rust の型システムを使用してダックタイピングを活用したコードに似た 
コードを書くことの利点は、実行時に値が特定のメソッドを実装しているか確認したり、値がメソッ 
ドを実装していない時にエラーになることを心配したりする必要は絶対になく、とにかく呼び出せる 
ことです。コンパイラは、値が、トレイトオブジェクトが必要としているトレイトを実装していなけ 
れば、コンパイルを通さないのです。 

例えば、リスト 17-10 は、コンポーネントに String のある Screen を作成しようとした時に起こ 
ることを示しています： 

フアイル名： src / main.rs 

extern crate gui ; 
use gun :: Screen; 

fn main() { 

let screen = Screen { 
components: vec! [ 

Box :: new(Stri ng: : from ("Hi ") ) ， 

], 

}； 


screen . run (); 

} 

リスト 17-10: トレイトオブジェクトのトレイトを実装しない型の使用を試みる 

String は Draw トレイトを実装していないので、このようなエラーが出ます： 

error[E0277] : the trait bound std :: string: : String: gun :: Draw is not satisfied 
--> src/main.rs:7:13 

I 

7 | Box :: new(String: : from("Hi")), 

| 八八八八八八八八八八八八八八八八八八八八八八八八八八八八 the gu~i**Dr"aw "is not 

impLemented for 'std::string::String' 

I i 

= note : required for the cast to the object type ' gui :: Draw ' 

このエラーは、渡すことを意図していないものを Screen に渡しているので、異なる型を渡すべき 
か、 Screen が draw を呼び出せるように String に Draw を実装するべきのどちらかであることを知ら 
せてくれています。 

17.2.3 トレイトオブジェクトは、ダイナミックディスパッチを行う 

第10章の「ジェネリクスを使用したコードのパフォーマンス」節でジェネリクスに対してトレイ 
卜境界を使用した時に、コンパイラが行う単相化過程の議論を思い出してください：コンパイラは、 
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関数やメソッドのジェネリックでない実装を、ジェネリックな型引数の箇所に使用している具体的な 
型に対して生成するのでした。単相化の結果吐かれるコードは、スタティックディスパッチを行い、 
これは、コンパイル時にコンパイラがどのメソッドを呼び出しているかわかる時のことです。これは、 
ダイナミックディスパッチとは対照的で、この時、コンパイラは、コンパイル時にどのメソッドを呼 
び出しているのかわかりません。ダイナミックディスパッチの場合、コンパイラは、実行時にどのメ 
ソッドを呼び出すか弾き出すコードを生成します。 

トレイトオブジェクトを使用すると、コンパイラはダイナミックディスパッチを使用しなければな 
りません。コンパイラは、トレイトオブジェクトを使用しているコードで使用される可能性のある型 
全てを把握しないので、どの型に実装されたどのメソッドを呼び出すかわからないのです。代わりに 
実行時に、トレイトオブジェクト内でポインタを使用して、コンパイラは、どのメソッドを呼ぶか知 
ります。スタティックディスパッチでは行われないこの検索が起きる時には、実行時コストがありま 
す。また、ダイナミックディスパッチは、コンパイラがメソッドのコードをインライン化することも 
妨げ、そのため、ある種の最適化が不可能になります。ですが、リスト 17-5 で記述し、リスト 17-9 
ではサボートできたコードで追加の柔軟性を確かに得られたので、考慮すべき代償です。 

17.2.4 トレイトオブジェクトには、オブジェクト安全性が必要 

トレイトオブジェクトには、オブジェクト安全なトレイトしか作成できません。トレイトオブジェ 
クトを安全にする特性全てを司る複雑な規則がありますが、実際には、2つの規則だけが関係があり 
ます。トレイトは、トレイト内で定義されているメソッド全てに以下の特性があれば、オブジェクト 
安全になります。 

• 戻り値の型が Self でない。 

• ジヱネリックな型引数がない。 

Self キーワードは、トレイトやメソッドを実装しようとしている型の別名です。トレイトオブジェ 
クトは、一旦、トレイトオブジェクトを使用したら、コンパイラにはそのトレイトを実装している具 
体的な型を知りようがないので、オブジヱクト安全でなければなりません。トレイトメソッドが具体 
的な Self 型を返すのに、トレイトオブジェクトが Self の具体的な型を忘れてしまったら、メソッ 
ドが元の具体的な型を使用できる手段はなくなってしまいます。同じことがトレイトを使用する時に 
具体的な型引数で埋められるジ x ネリックな型引数に対しても言えます：具体的な型がトレイトを実 
装する型の一部になるのです。トレイトオブジェクトの使用を通して型が忘却されたら、そのジヱネ 
リックな型引数を埋める型がなんなのか知る術はないのです。 

メソッドがオブジェクト安全でないトレイトの例は、標準ライブラリの Clone トレイトです 。 Clone 
トレイトの clone メソッドのシグニチヤは以下のような感じです： 


pub trait し Lone i 

fn clone (& self ) -> Self ; 

} 
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Str*i ng 型は Clone トレイトを実装していて、 String のインスタンスに対して clone メソッドを呼 
び出すと、 String のインスタンスが返ってきます。同様に、 Vec く T> のインスタンスに対して clone 
を呼び出すと、 Vec く T> のインスタンスが返ってきます。 clone のシグニチャは、 Self の代わりに入る 
型を知る必要があります。それが、戻り値の型になるからです。 

コンパイラは、トレイトオブジェクトに関していつオブジェクト安全の規則を侵害するようなこと 
を試みているかを示唆します。例えば、リスト 17-4 で Screen 構造体を実装して Draw トレイトでは 
なく、 Clone トレイトを実装した型を保持しようとしたとしましょう。こんな感じで： 


pub struct bcreen { 

pub components: Vec<Box<Clone >> ， 

} 


こんなエラーになるでしよう： 


error[E0038]: the trait 'std: : clone: : Clone' cannot be made into an object 
(エラー： 'std: : clone: : Clone' トレイトは、オブジェクトにすることはできません） 
-- > src/lnb.rs :2:5 


2 | pub components : Vec<Box<Clone>> , 

| 八八八八八八八八八八八八八八八八八八八八八八八八八八八八八八八 the ■trail; 

made into an object 


std :: clone : :Clone 


=note : the trait cannot require that 'Self : Sized' 
( 注釈：このトレイトは 、 'Self : Sized' を満たせません） 


cannot be 


このエラーは、このようにこのトレイトをトレイトオブジェクトとして使用することはできないこ 
とを意味しています。オブジヱクト安全性についての詳細に興味があるのなら 、 Rust RFC 255を参 
照されたし。 


17.3 オブジェクト指向デザインパターンを実装する 

ステートパターンは、オブジェクト指向デザインパターンの1つです。このパターンの肝は、値が 
一連のステートオブジェクトで表されるなんらかの内部状態を持ち、その内部の状態に基づいて値の 
振る舞いが変化するというものです。ステートオブジェクトは、機能を共有します： Rust では、もち 
ろん、オブジェクトと継承ではなく、構造体とトレイトを使用します。各ステートオブジェクトは、 
自身の振る舞いと別の状態に変化すべき時を司ることに責任を持ちます。ステートオブジェクトを保 
持する値は、状態ごとの異なる振る舞いや、いつ状態が移行するかについては何も知りません。 

ステートパターンを使用することは、プログラムの業務用件が変わる時、状態を保持する値のコー 
ドや、値を使用するコードを変更する必要はないことを意味します。ステートオブジェクトの1つの 
コードを更新して、規則を変更したり、あるいはおそらくステートオブジェクトを追加する必要しか 
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ないのです。ステートデザインパターンの例と、その Rust での使用方法を見ましょう。 

ブログ記事のワークフローを少しずつ実装していきます。ブログの最終的な機能は以下のような感 
じになるでしょう： 

1. ブログ記事は、空の草稿から始まる。 

2. 草稿ができたら、査読が要求される。 

3. 記事が承認されたら、公開される。 

4. 公開されたブログ記事だけが表示する内容を返すので、未承認の記事は、誤って公開されない。 

それ以外の記事に対する変更は、効果を持つべきではありません。例えば、査読を要求する前にブ 
ログ記事の草稿を承認しようとしたら、記事は、非公開の草稿のままになるべきです。 

リスト 17-11 は、このワークフローをコードの形で示しています：これは、 blog というライブラリ 
クレートに実装する API の使用例です。まだ blog クレートを実装していないので、コンパイルはで 
きません。 

フ アイ ル名： src / main.rs 

extern crate blog ; 

use blog : : Post ; 

fn main () { 

let mut post = Post :: new (); 

// 今日はお昼にサラダを食べた 

post . add _ text("I ate a salad for lunch today ") ; 

assert _ eq ! , post • content ()); 

post . request _ review (); 

assert _ eq ! , post • content ()); 

post • approve (); 

assert _ eq! ("I ate a salad for lunch today " , post . content ()); 

} 

リスト 17-11: blog クレートに欲しい振る舞いをデモするコード 

ユーザが Post : : new で新しいブログ記事の草稿を作成できるようにしたいです。それから、草稿状 
態の間にブログ記事にテキストを追加できるようにしたいです。承認前に記事の内容を即座に得よう 
としたら、記事はまだ草稿なので、何も起きるべきではありません。デモ目的でコードに assert _ eq ! 
を追加しました。これに対する素晴らしい単体テストは、ブログ記事の草稿が content メソッドから 
空の文字列を返すことをアサートすることでしょうが、この例に対してテストを書くつもりはありま 
せん。 

次に、記事の査読を要求できるようにしたく、また査読を待機している間は content に空の文字列 
を返してほしいです。記事が承認を受けたら、公開されるべきです。つまり、 content を呼んだ時に 
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記事のテキストが返されるということです。 

クレートから相互作用している唯一の型は、 Post だけであることに注意してください。この型はス 
テ ー トパターンを使用し、記事がなり得る種々の状態を表す3つのステートオブジェクトのうちの1 
つになる値を保持します。草稿、査読待ち、公開中です。 1 つの状態から別の状態への変更は、 Post 
型内部で管理されます。 Post インスタンスのライブラリ使用者が呼び出すメソッドに呼応して状態は 
変化しますが、状態の変化を直接管理する必要はありません。また、ユーザは、査読前に記事を公開 
するなど状態を誤ることはありません。 

17.3.1 Post を定義し、草稿状態で新しいインスタンスを生成する 

ライブラリの実装に取り掛かりましょう！なんらかの内容を保持する公開の Post 構造体が必要な 
ことはわかるので、構造体の定義と、関連する公開の Post インスタンスを生成する new 関数から始 
めましょう。リスト 17-12 のようにですね。また、非公開の State トレイトも作成します。それか 
ら、 Post は state という非公開のフィールドに、 Option で Box<State> のトレイトオブジヱクトを保 
持します。 Option が必要な理由はすぐわかります。 

ファイル名： src / lib.rs 

pub struct Post { 

state : Option<Box<State>> , 
content : String, 

} 

impl Post { 

pub fn new() -> Post { 

Post { 

state : Some(Box: : new(Draft {}))， 
content: Stri ng: :new () ， 



trait State {} 

struct Draft {} 

impl State for Draft {} 

リスト 17-12: Post 構造体、新規 Post インスタンスを生成する new 関数、 State トレイト 、 Draft 
構造体の定義 

State トレイトは、異なる記事の状態で共有される振る舞いを定義し、 Draft、Pendi ngReview 、 
Published 状態は全て、 State トレイトを実装します。今は、トレイトにメソッドは何もなく 、 Draft 
が記事の初期状態にしたい状態なので、その状態だけを定義することから始めます。 
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新しい Post を作る時、 state フィールドは、 Box を保持する Some 値にセットします 0 この Box が 
Draft 構造体の新しいインスタンスを指します。これにより、新しい Post を作る度に、草稿から始ま 
ることが保証されます。 Post の state フィールドは非公開なので、 Post を他の状態で作成する方法 
はないのです！ Post : : new 関数では、 content フイールドを新しい空の Stri ng にセットしています。 

17.3.2 記事の内容のテキストを格納する 

リスト 17-11 は、 add _ text というメソッドを呼び出し、ブログ記事のテキスト内容に追加される 
& str を渡せるようになりたいことを示しました。これを content フィールドを pub にして晒すので 
はなく、メソッドとして実装しています。これは、後ほど content フィールドデータの読まれ方を制 
御するメソッドを実装できることを意味しています 。 adcLtext メソッドは非常に素直なので、リスト 
17-13 の実装を impl Post ブロックに追加しましょう： 

ファイル名： src / lib.rs 

# pub struct Post i 

# content : String , 

# } 

# 

impl Post { 

// -- snip -- 

pub fn add _ text (&mut self , text : & str ) { 
self . content . push _ str ( text ); 

} 

} 

リスト 17-13: 記事の content にテキストを追加する add_text メソッドを実装する 

add_text メソッドは、 self への可変参照を取ります。というのも、 add_text を呼び出した Post 
インスタンスを変更しているからです。それから content の String に対して push_str を呼び出し、 
text 引数を渡して保存された content に追加しています。この振る舞いは、記事の状態によらないの 
で、ステートパターンの一部ではありません。 add_text メソッドは、 state フィールドと全く相互作 
用しませんが、サポートしたい振る舞いの一部ではあります。 

17.3.3 草稿の記事の内容は空であることを保証する 

add _ text を呼び出して記事に内容を追加した後でさえ、記事はまだ草稿状態なので、それでも 
content メソッドには空の文字列スライスを返してほしいです。リスト 17-11 の8行目で示したよう 
にですね。とりあえず、この要求を実現する最も単純な方法で content メソッドを実装しましょう： 
常に空の文字列スライスを返すことです。一旦、記事の状態を変更する能力を実装したら、公開でき 
るように、これを後ほど変更します。ここまで、記事は草稿状態にしかなり得ないので、記事の内容 
は常に空のはずです。リスト 17-14 は、この仮の実装を表示しています： 



第 17 章 Rust のオブジェクト指向プログラミング機能 


418 


ファイル名： src/lib.rs 

# pub struct Post { 

# content : String, 

# } 

# 

impl Post { 

// --snip-- 

pub fn content(&self) -> &str { 



リスト 17-14： Post に常に空の文字列スライスを返す content の仮の実装を追加する 

この追加された content メソッドとともに、リスト 17-11 の8行目までのコードは、想定通り動 
きます。 

17.3.4 記事の査読を要求すると、状態が変化する 

次に、記事の査読を要求する機能を追加する必要があり、これをすると、状態が Draft から 
Pendi ngReview に変わるはずです。リスト 17-15 はこのコードを示しています： 

ファイル名： src/lib.rs 

# pub struct Post { 

# state : Option<Box<State>> , 

# content : String, 

# } 

# 

impl Post { 

// snip__ 

pub fn request_revi ew(&mut self) { 

if let Somers; = self .state.take() { 

self .state = Some(s. request_review()) 



} 

trait State { 

fn request_revi ew(self : Box<Self>) -> Box<State> ; 

} 

struct Draft {} 
impl State for Draft { 

fn request_revi ew(self : Box く Self 〉） -> Box く State 〉 { 
Box ::new(PendingReview {}) 

} 
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} 

struct PencnngReview {} 

impl State tor PendingReview { 

fn request_revi ew(self : Box く Self 〉） -> Box く State 〉 { 
self 

} 

} 

リスト 17-15: Post と State トレイトに request_revi ew メソッドを実装する 

Post に self への可変参照を取る request_review という公開メソッドを与えます。それから 、 Post 
の現在の状態に対して内部の request_review メソッドを呼び出し、この 2 香目の request_review 
が現在の状態を消費し、新しい状態を返します。 

State トレイトに request_review メソッドを追加しました；このトレイトを実装する型は全て、こ 
れで request_ review メソッドを実装する必要があります。メソッドの第 1 引数に self 、 &self 、 
&mut self ではなく、 self: Box く Self 〉 としていることに注意してください。この記法は、型を保持 
する Box に対して呼ばれた時のみ、このメソッドが合法になることを意味しています。この記法は、 
Box く Self> の所有権を奪い、古い状態を無効化するので、 Post の状態値は、新しい状態に変形でき 
ます。 

古い状態を消費するために 、 requestjeview メソッドは、状態値の所有権を奪う必要があります。 
ここで Post の state フィールドの Option が問題になるのです ： take メソッドを呼び出して 、 state 
フィールドから Some 値を取り出し、その箇所に None を残します。なぜなら、 Rust は、構造体に未 
代入のフィールドを持たせてくれないからです。これにより、借用するのではなく、 Post の state 値 
をムーブすることができます。それから、記事の state 値をこの処理の結果にセットするのです。 

self.state = self. state • request_review() ; のようなコードで直接 state 値の所有権を得るよ 
う設定するのではなく、一時的に None に state をセットする必要があります。これにより、新しい 
状態に変形した後に、 Post が古い state 値を使えないことが保証されるのです。 

Draft の request_review メソッドは、新しい Pendi ngReview 構造体の新しいボックスのインスタ 
ンスを返す必要があり、これが、記事が査読待ちの時の状態を表します 。 Pendi ngReview 構造体も 
requestjeview メソッドを実装しますが、何も変形はしません。むしろ、自身を返します。というの 
も、既に PendingReview 状態にある記事の査読を要求したら、 PendingReview 状態に留まるべきだか 
らです。 

ようやくステートパターンの利点が見えてき始めました： state 値が何であれ、 Post の 
request_r"eview メソッドは同じです。各状態は、独自の規則にのみ責任を持ちます。 

Post の content メソッドを空の文字列スライスを返してそのままにします。これで Post は 
PendingReview と Draft 状態になり得ますが、 PendingReview 状態でも、同じ振る舞いが欲しいです。 
もうリスト 17-11 は11行目まで動くようになりました！ 
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17.3 .5 content の振る舞いを変化させる approve メソッドを追加する 

approve メソッドは、 request_revi ew メソッドと類似するでしょう：状態が承認された時に、現在 
の状態があるべきと言う値に state をセットします。リスト 17-16 のようにですね： 

ファイル名： src/lib.rs 

# pub struct Post { 

# state : Option<Box<State>> , 

# content : String, 

# } 

# 

impl Post { 

// --snip__ 

pub fn approve(&mut self) { 

if let Somers; = self .state.take() { 
seIf .state = Some (s.approve()) 



} 

trait State { 

fn request_revi ew(self : Box<Self>) -> Box<State> ; 
fn approve(self : Box く Self 〉） -> Box く State 〉； 

} 

struct Draft {} 
impl State for Draft { 

# fn request.review (self: Box<Self>) -> Box<State> { 

# Box ::new(PendingReview {}) 

# } 

# 

// --snip-- 

fn approve(self : Box く Self 〉） -> Box く State 〉 { 
self 



struct PendingReview {} 
impl State for PendingReview { 

# fn request_review(self: Box<Self>) -> Box<State> { 

# self 

# } 

# 

// --snip__ 

fn approve(self: Box く Self 〉） -> Box く State 〉 { 

Box: : new(Published {}) 

} 
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} 

struct Published {} 


impl State for Published { 

fn request_revi ew(self : Box く Self 〉） -> Box く State 〉 { 
self 

} 

fn approve(self : Box く Self 〉） -> Box く State 〉 { 
self 

} 

} 

リスト 17-16: Post と State トレイトに approve メソツドを実装する 

State トレイトに approve メソッドを追加し、 Published 状態という State を実装する新しい構造 
体を追加します。 

requestjeview のように、 Draft に対して approve メソッドを呼び出したら、 self を返すので、何 
も効果はありません。 Pendi ngReview に対して approve を呼び出すと、 Published 構造体の新しいボッ 
クス化されたインスタンスを返します。 Published 構造体は State トレイトを実装し、 request_review 
メソッドと approve メソッド両方に対して、自身を返します。そのような場合に記事は、 Published 
状態に留まるべきだからです。 

さて、 Post の content メソッドを更新する必要が出てきました：状態が Published なら、記事の 
content フィールドの値を返したいのです；それ以外なら、空の文字列スライスを返したいです。リス 
卜 17-17 のようにですね： 

ファイル名： src / lib.rs 

# trait State { 

# fn content<'a> (&self , post: &'a Post) -> &'a str ; 

# } 

# pub struct Post { 

# state : Option<Box<State>> , 

# content : String, 

# } 

# 

impl Post { 

// --snip-- 

pub fn content(&self ) -> &str { 

self .state.as_ref () .unwrapO .content (&self) 

} 

// --snip__ 

} 


リスト 17-17: Post の content メソッドを更新して State の content メソッドに委譲する 
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目的は、これらの規則全てを State を実装する構造体の内部に押し留めることなので、 state の値 
に対して content メソッドを呼び出し、記事のインスタンス（要するに 、 self ) を引数として渡しま 
す。そして、 state 値の content メソッドを使用したことから返ってきた値を返します。 

Option に対して as_ref メソッドを呼び出します。値の所有権ではなく、 Option 内部の値への参照 
が欲しいからです 0 state は Option<Box<State>> なので、 as_ref を呼び出すと、 Option<&Box<State 
>> が返ってきます。 as_ref を呼ばなければ、 state を関数引数の借用した &self からムーブできない 
ので、エラーになるでしよう。 

さらに unwrap メソッドを呼び出し、これは絶対にパニックしないことがわかっています。何故な 
ら、 Post のメソッドが、それらのメソッドが完了した際に state は常に Some 値を含んでいることを 
保証するからです。これは、コンパイラには理解不能であるものの、 None 値が絶対にあり得ないとわ 
かる第9章の「コンパイラよりも情報を握っている場合」節で語った一例です。 

この時点で、 &Box<State> に対して content を呼び出すと、参照外し型強制が & と Box に働くので、 
究極的に content メソッドが State トレイトを実装する型に対して呼び出されることになります。つ 
まり、 content を State トレイト定義に追加する必要があり、そこが現在の状態に応じてどの内容を 
返すべきかというロジックを配置する場所です。リスト 17-18 のようにですね： 

ファイル名： src/lib.rs 


# pub struct Post { 

# content : String 

# } 

trait State { 

// --snip-- 

fn content く ， a> (&self ， post: &'a Post) -> &'a str { 



// --snip-- 
struct Published {} 

impl State for Published { 

// snip 

fn content<'a> (&self , post : &'a Post) -> &'a str { 

&post.content 

} 

} 

リスト 17-18: State トレイトに content メソツドを追加する 

空の文字列スライスを返すデフォルト実装を content メソッドに追加しています。これによ 
り、 Draft と PendingReview 構造体に content を実装する必要はありません。 Published 構造体は、 
content メソツドをオーバーライドし 、 post • content の値を返します。 

第 10 章で議論したように、このメソッドにはライフタイム注釈が必要なことに注意してください。 
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post への参照を引数として取り、その post の一部への参照を返しているので、返却される参照のラ 
イフタイムは、 post 引数のライフタイムに関連します。 

出来上がりました。要するに、リスト 17-11 はもう動くようになったのです！ブログ記事ワーク 
フローの 規則でステ ー トパターンを実装しました。その規則に関連するロジックは、 Post 中に散乱す 
るのではなく、ステートオブジェクトに息づいています。 

17.3.6 ステートパターンの代償 

オブジェクト指向のステートパターンを実装して各状態の時に記事がなり得る異なる種類の振る舞 
いをカプセル化する能力が、 Rust にあることを示してきました。 Post のメソッドは、種々の振る舞 
いについ ては何も知りません。コードを体系化する仕方によれば、公開された記事が振る舞うことの 
ある様々な方法を知るには、 1 箇所のみを調べればいいのです： Publi shed 構造体の State トレイト 
の実装です。 

ステートパターンを使用しない対立的な実装を作ることになったら、代わりに Post のメソッドか、 
あるいは記事の状態を確認し、それらの箇所（編注： Post のメソッドのことか）の振る舞いを変更する 
main コードでさえ、 match 式を使用したかもしれません 0 そうなると、複数個所を調べて記事が公開 
状態にあることの裏の意味全てを理解しなければならなくなります！これは、追加した状態が増えれ 
ば、さらに上がるだけでしょう：各 match 式には、別のアームが必要になるのです。 

ステ ー トパターンでは、 Post のメソッドと Post を使用する箇所で、 match 式が必要になることは 
なく、新しい状態を追加するのにも、新しい構造体を追加し、その1つの構造体にトレイトメソッド 
を実装するだけでいいわけです。 

ステートパターンを 使用した実装は、拡張して機能を増やすことが容易です。 ステートパターンを 
使用するコードの管理の単純さを確認するために、以下の提言を試してみてください： 

• 記事の状態を PendingReview から Draft に民す reject メソッドを追加する 0 

• 状態が Published に変化させられる前に approve を 2 回呼び出す必要があるようにする。 

• 記事が Draft 状態の時のみテキスト内容をユーザが追加できるようにする。ヒント：ステート 
オブジェクトに内容について変わる可能性のあるものの責任を持たせつつも、 Post を変更する 
ことには責任を持たせない。 

ステートパターンの欠点の1つは、状態が状態間の遷移を実装しているので、状態の一部が密に結 
合した状態になってしまうことです。 PendingReview と Published の間に、 Scheduled のような別の 
状態を追加したら、代わりに Pendi ngReview のコードを Scheduled に遷移するように変更しなけれ 
ばならないでしょう。状態が追加されても PendingReview を変更する必要がなければ、作業が減りま 
すが、そうすれば別のデザインパターンに切り替えることになるでしょう。 

別の欠点は、ロジックの一部を重複させてしまうことです。重複を除くためには、 State トレイト 
の request_ review と approve メソッドに self を返すデフォルト実装を試みる可能性があります；で 
すが、これはオブジヱクト安全性を侵害するでしょう。というのも、具体的な self が一体なんなの 
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かトレイトには知りようがないからです。 State をトレイトオブジェクトとして使用できるようにし 
たいので、メソッドにはオブジェクト安全になってもらう必要があるのです。 

他の童複には、 Post の request, ■ review と approve メソッ ドの実装が似ていることが含まれます。 
両メソッドは Option の state の値に対する同じメソッドの実装に委譲していて、 state フィールド 
の新しい値を結果にセットします。このパターンに従う Post のメソッドが多くあれば、マクロを定 
義して繰り返しを排除することも考慮する可能性があります（マクロについては付録 D を参照)。 

オブジヱクト指向言語で定義されている通り忠実にステートパターンを実装することで、 Rust の 
強みをできるだけ発揮していません。 blog クレートに対して行える無効な状態と遷移を コンパイルエ 
ラーにできる変更に目を向けましょう。 

17.3.6.1 状態と振る舞いを型としてコード化する 

ステー トパターンを再考して別の代償を得る方法をお見せします。状態と遷移を完全に カプセル 化 
して、外部のコードに知らせないようにするよりも、状態を異なる型にコード化します。結果的に、 
Rust の型検査 システムが、 公開記事のみが許可される箇所で草稿記事の使用を試みることをコンパ 
イルエラ ーを発して阻止します。 

リスト 17-11 の main の最初の部分を考えましょう： 

ファイル名： src / main.rs 

fn mann() { 

let mut post = Post :: new(); 

post.add_text ("I ate a salad for lunch today") ; 
assert_eq !(’’" ， post. content ()); 

} 

それでも、 Post:: new で草稿状態の新しい記事を生成することと記事の内容にテキストを追加する 
能力は可能にします。しかし、空の文字列を返す草稿記事の content メソッドを保持する代わりに、 
草稿記事は、 content メソッドを全く持たないようにします。そうすると、草稿記事の内容を得よう 
としたら、メソッドが存在しないという コンパイル エラーになるでしょう。その結果、誤ってプロダ 
クシ ヨン コードで草稿記事の内容を表示することが不可能になります。そのようなコードは、 コンパ 
イルさえできないからです。リスト 17-19 は Post 構造体、 DraftPost 構造体、さらにメソッドの定 
義を示しています： 

ファイル名： src / lib.rs 

pub struct Post { 
content : String, 

} 


pub struct DraftPost { 
content : String, 
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} 

impl Post { 

pub fn new() -> DraftPost { 

DraftPost { 

content: Stri ng: : new(), 

} 

} 

pub fn content(&self) -> &str { 

&self. content 

} 

} 

impl DraftPost { 

pub fn add_text (&mut self, text : &str) { 
self .content.push_str(text); 

} 

} 

リスト 17-19: content メソッドのある Post と content メソッドのない DraftPost 

Post と DraftPost 構造体どちらにもブログ記事のテキストを格納する非公開の content フィール 
ドがあります。状態のコード化を構造体の型に移動したので、この構造体は最早 state フィールドを 
持ちません。 Post は公開された記事を表し、 content を返す content メソッドがあります。 

それでも Post: : new 関数はありますが、 Post のインスタンスを返すのではなく、 DraftPost のイン 
スタンスを返します。 content は非公開であり、 Post を返す関数も存在しないので、現状 Post のイ 
ンスタンスを生成することは不可能です。 

DraftPost 構造体には、以前のようにテキストを content に追加できるよう add_text メソッドが 
ありますが、 DraftPost には content メソッドが定義されていないことに注目してください！従っ 
て、これでプログラムは、全ての記事が草稿記事から始まり、草稿記事は表示できる内容がないこと 
を保証します。この制限をかいくぐる試みは、全てコンパイルエラーに落ち着くでしょう。 

17.3.6.2 遷移を異なる型への変形として実装する 
では、どうやって公開された記事を得るのでしょうか？公開される前に草稿記事は査読され、承認 
されなければならないという規則を強制したいです。査読待ち状態の記事は、それでも内容を表示す 
るべきではありません。別の構造体 Pendi ngRevi ewPost を追加し、 DraftPost に Pendi ngRevi ewPost 
を返す request_revi ew メソッドを定義し、 Pendi ngRevi ewPost に Post を返す approve メソッドを 
定義してこれらの制限を実装しましょう。リスト 17-20 のようにですね： 

ファイル名： src / lib.rs 

# pub struct Post i 

# content : String, 
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# } 

# 

# pub struct DraftPost { 

# content : String, 

# } 

# 

impl DraftPost { 

// snip__ 

pub fn request_revi ew(self ) -> PendingReviewPost { 

PendingReviewPost { 

content: self .content, 

} 

} 

} 

pub struct PendingReviewPost { 
content : String, 

} 

impl PendingReviewPost { 

pub fn approve(self ) -> Post { 

Post { 

content : self .content, 

} 

} 

} 

リスト 17-20: DraftPost の request_review を呼び出すことで生成される Pendi ngRevi ewPost と、 
Pendi ngRevi ewPost を公開された Post に変換する approve メソッド 

request_review と approve メ ソツドは self の所有権を奪い、故に DraftPost と Pendi ngRevi ewPost 
インスタンスを消費し、それぞれ PendingReviewPost と公開された Post に変形します。このよう 
に、 DraftPost インスタンスに request_review を呼んだ後には、 DraftPost インスタンスは生きな 
がらえず、以下同様です。 Pendi ngRevi ewPost 構造体には、 content メソッドが定義されていないの 
で、 DraftPost 同様に、その内容を読もうとするとコンパイルエラーに落ち着きます。 content メ 
ソッドが確かに定義された公開された Post インスタンスを得る唯一の方法が、 Pendi ngRevi ewPost 
に対して approve を呼び出すことであり、 Pendi ngRevi ewPost を得る哨一 ^ の方法が、 DraftPost に 
request.review を呼び出すことなので、これでブログ記事のワークフローを型システムにコード化 
しました。 

ですが、さらに main にも 多少 小さな変更を行わなければなりません。 request_review と approve 
メソッドは、呼ばれた構造体を変更するのではなく、新しいインスタンスを返すので、 let post = と 
いうシャドーイング代入をもっと追加し、返却されたインスタンスを保存する必要があります。また、 
草稿と査読待ち記事の内容を空の文字列でアサートすることも、する必要もありません：最早、その 
状態にある記事の内容を使用しようとするコードはコンパイル不可能だからです。 main の更新された 
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コードは、リスト 17-21 に示されています： 

フアイル名： src/main.rs 

extern crate blog ; 
use blog : : Post ; 

fn main () { 

let mut post = Post :: new (); 

post . add _ text("I ate a salad for lunch today ") ; 
let post = post . request _ review (); 


let post = post • approve (); 

assert _ eq! ("I ate a salad for lunch today " , post . content ()); 

} 

リスト 17-21： ブログ記事ワークフローの新しい実装を使う main の変更 

post を再代入するために main に行う必要のあった変更は、この実装がもう、全くオブジヱクト指 
向のステートパターンに沿っていないことを意味します：状態間の変形は最早、 Post 実装内に完全に 
カプセル化されていません。ですが、型システムとコンパイル時に起きる型チヱックのおかげでもう 
無効な状態があり得なくなりました。これにより、未公開の記事の内容が表示されるなどの特定のパ 
グが、プロダクシヨンコードに移る前に発見されることが保証されます。 

blog クレートに関してこの節の冒頭で触れた追加の要求に提言される作業をそのままリスト 17-20 
の後に試してみて、このバージヨンのコードについてどう思うか確かめてください。この設計では、 
既に作業の一部が達成されている可能性があることに注意してください。 

Rust は、オブジェクト指向のデザインパターンを実装する能力があるものの、状態を型システムに 
コード化するなどの他のパターンも、 Rust では利用可能なことを確かめました。これらのパターンに 
は、異なる代償があります。あなたが、オブジェクト指向のパターンには非常に馴染み深い可能性が 
あるものの、問題を再考して Rust の機能の強みを活かすと、コンパイル時に一部のバグを回避でき 
るなどの利益が得られることもあります。オブジェクト指向のパターンは、オブジェクト指向言語に 
はない所有権などの特定の機能により Rust では、必ずしも最善の解決策ではないでしょう。 

17.4 まとめ 

この章読了後に、あなたが Rust はオブジェクト指向言語であると考えるかどうかに関わらず、も 
うトレイトオブジェクトを使用して Rust でオブジェクト指向の機能の一部を得ることができると 
知っています。ダイナミックディスパッチは、多少の実行時性能と引き換えにコードに柔軟性を齎（も 
たら）してくれます。この柔軟性を利用してコードのメンテナンス性に寄与するオブジェクト指向パ 
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ターンを実装することができます。 Rust にはまた、オブジェクト指向言語にはない所有権などの他の 
機能もあります。オブジェクト指向パターンは、必ずしも Rust の強みを活かす最善の方法にはなり 
ませんが、利用可能な選択肢の1つではあります。 

次は、パターンを見ます。パターンも多くの柔軟性を可能にする Rust の別の機能です。本全体を 
通して僅かに見かけましたが、まだその全能力は目の当たりにしていません。さあ、行きましょう！ 
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パターンとマッチング 


パターンは、複雑であれ、単純であれ、 Rust で型の構造に一致する特別な記法です。 match 式や 
他の構文と組み合わせてパターンを使用すると、プログラムの制御フローをよりコントロールできま 
す。パターンは、以下を組み合わせることで構成されます： 

• リテラル" 

• 分配された配列、 enum 、 構造体、タプル 
• 変数 

• ワイルドカード 
• プレースホルダー 

これらの要素が取り組んでいるデータの形を説明し、それから値に対してマッチを行い、プログラ 
ムに正しい値があって特定のコードを実行し続けられるかどうかを決定します。 

パターンを使用するには、なんらかの値と比較します。パターンが値に合致したら、コードで値の 
部分を使用します。コイン並び替えマシンの例のような第6章でパターンを使用した match 式を思い 
出してください。値がパターンの形に当てはまったら、名前のある部品を使用できます。当てはまら 
なければ、パターンに紐づいたコードは実行されません。 

この章は、パターンに関連するあらゆるものの参考文献です。パターンを使用するのが合法な箇所、 
論駁（ろんばく）可能と論駁不可能なパターンの違い、目撃する可能性のある色々な種類のパターン記 
法を講義します。章の終わりまでに、パターンを使用して多くの概念をはっきり表現する方法を知る 
でしよう。 

18.1 パターンが使用されることのある箇所全部 


Rust において、パターンはいろんな箇所に出現し、そうと気づかないうちにたくさん使用してきま 
した！この節は、パターンが合法な箇所全部を議論します。 
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18.1.1 match アー厶 

第 6 章で議論したように、パターンを match 式のアームで使います。正式には、 match 式はキー 
ワード match 、 マッチ対象の値、パターンとそのアームのパターンに値が合致したら実行される式か 
らなる 1 つ以上のマッチアームとして定義されます。以下のように： 

match VALUE { 

PATTERN => EXPRESSION, 

PATTERN => EXPRESSION, 

PATTERN => EXPRESSION, 

} 

match 式の必須事項の 1 つは、 match 式の値の可能性全てが考慮されなければならないという意味 
で網羅的である必要があることです。全可能性をカバーしていると保証する1つの手段は、最後の 
アームに 包括的なパターンを入れることです：例えば、どんな値にも合致する変数名は失敗すること 
があり得ないので、故に残りの全ケースをカバーできます。 

_という特定のパターンは何にでもマッチしますが、変数には束縛されないので、よく最後のマッ 
チアームに 使用されます。例えば、_パターンは、指定されていないあらゆる値を無視したい時に有 
用です。_パターンについて詳しくは、この章の後ほど、「パターンで値を無視する」節で講義します。 

18.1.2 条件分岐 if let 式 

第6章で主に if let 式を1つの場合にしか合致しない match と同様のものを書く省略法として使 
用する方法を議論しました。オプションとして 、 if let には if let のパターンが合致しない時に走 
るコードを含む対応する else も用意できます。 

リスト 18-1 は 、 if let、else if、else if let 式を混ぜてマッチさせることもできることを示 
しています。そうすると、パターンと1つの値しか比較することを表現できない match 式よりも柔軟 
性が高くなります。また、一連の if let、else if、else if let アームの条件は、お互いに関連し 
ている必要はありません。 

リスト 18-1 のコードは、背景色が何になるべきかを決定するいくつかの条件を連なって確認する 
ところを示しています。この例では、実際のプログラムではユーザ入力を受け付ける可能性のある変 
数を ハー ドコードされた値で生成しています。 

フアイル名： src / main.rs 
fn mann() { 

let favorite_color: 0ption<&str> = None ; 

let is_tuesday = false ; 

let age : Result<u8 , _> = "34" .parse(); 

i r let Some (color) = favorite_color { 

// あなたのお気に入りの色、 {} を背景色に使用します 
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pnntln ! ("Usi ng your favorite color, {}，as the background" , color); 
} else if is_tuesday { 

// 火曜日は緑の日！ 

println! ("Tuesday is green day! ") ; 

} else if let Ok(age) = age { 
if age > 30 { 

// 紫を背景色に使用します 

println! ("Using purple as the background color") ; 

} else { 

// オレンジを背景色に使用します 

println! ("Using orange as the background color") ; 

} 

} else { 

// 青を背景色に使用します 

println ! ("Usi ng blue as the background color") ; 



リスト 18-1: let、else if、else if let、else を混ぜる 

ユーザがお気に入りの色を指定したら、その色が背景色になります。今日が火曜日なら、背景色は 
緑です。ユーザが年齢を文字列で指定し、数値として解析することができたら、背景色は、その数値 
の値によって紫かオレンジになります。どの条件も適用できなければ、背景色は青になります： 

この条件分岐構造により、複雑な要件をサポートさせてくれます。ここにあるハードコードされた 
値では、この例は Using purple as the background color と出力するでしょう。 

match アームのように if let もシャドーイングされた変数を導入できることがわかります ： if let 
Ok(age) = age の行は、 Ok 列挙子の中の値を含むシャドーイングされた新しい age 変数を導入しま 
す。つまり 、 if age > 30 という条件は、そのブロック内に配置する必要があります：これら2つの 
条件を組み合わせて 、 if let Ok(age) = age && age > 30 とすることはできません。 30 と比較した 
いシャドーイングされた age は、波括弧で新しいスコープが始まるまで有効にならないのです。 

if let 式を使うことの欠点は、コンパイラが網羅性を確認してくれないことです。一方で match 式 
ではしてくれます。最後の else ブロックを省略して故に、扱い忘れたケースがあっても、コンパイ 
ラは、ロジックバグの可能性を指摘してくれないでしょう。 

18.1 .3 while let 条件分岐ループ 

if let と構成が似て 、 while let 条件分岐ループは、パターンが合致し続ける限り、 while ループ 
を走らせます。リスト 18-2 の例は、ベクタをスタックとして使用する while let ループを示し、ベ 
クタの値をプッシュしたのとは逆順に出力します： 

let mut stack = Vec :: new() ; 


stack. push(1) ; 
stack. push(2); 
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stack. push (3) ; 

while Let Some (top) = stack. pop() i 
println! ("{}", top); 

} 

リスト 18-2: while let ループを使って stack , pop () が Some を返す限り値を出力する 

この例は、3, 2,そして1と出力します 。 pop メソッドはベクタの最後の要素を取り出して Some ( 
value ) を返します。ベクタが空なら、 pop は None を返します。 while ループは pop が Some を返す限 
り、ブロックのコードを実行し続けます。 pop が None を返すと、ループは停止します 。 while let を 
使用してスタックから全ての要素を取り出せるのです。 

18.1 .4 for ループ 

第3章で、 Rust コードにおいては、 for ループが最もありふれたループ構造だと述べましたが、 
for が取るパターンについてはまだ議論していませんでした。 for ループにおいて、直接キーワード 
for に続く値がパターンなので、 for x in y では、 x がパターンになります。 

リスト 18-3 は for ループでパターンを使用して for ループの一部としてタプルを分配あるいは、 
分解する方法をデモしています。 

let v 二 vec ! ['a' , 'b' , ' c '] ; 

for い ndex , value ) in v . iter (). enumerate () { 

println ! ("{} is at index {}" , value , index ); 

} 

リスト 18-3: for ループでパターンを使用してタプルを分配する 
リスト 18-3 のコードは、以下のように出力するでしょう： 


a is at index 0 
b is at index 1 
c is at index 2 


enumerate メソッドを使用してイテ レー タを改造し、値とその値のイテ レー タでの添え字をタプル 
に配置して生成しています。 enumerate の最初の呼び出しは、タプル（0，4リを生成します。この値 
がパターン （ index , value ) とマッチさせられると、 index は0、 value は’ a ’ になり、出力の最初の 
行を出力するのです。 
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18.1.5 let 文 

この章に先駆けて、 match と if let でパターンを使用することだけ明不的に議銷してきましたが、 
実は let 文を含む他の箇所でもパターンを使用してきたのです。例として、この let での率直な変数 
代入を考えてください： 

let x = 5; 

この本を通してこのような let を何百回も使用してきて、お気付きではなかったかもしれません 
が、パターンを使用していたのです！より正式には、 let 文はこんな見た目をしています： 

let PATTERN = EXPRESSION ; 

let x = 5; のような変数名が PATTERN スロットにある文で、変数名は、ただ特に単純な形態の 
パターンなのです。 Rust は式をパターンと比較し、見つかったあらゆる名前を代入します。故に、 
let x = 5;の例では、 x は「ここでマッチしたものを変数 x に束縛する」ことを意味するパターンで 
す。名前 x がパターンの全容なので、このパターンは実質的に「値が何であれ、全てを変数 x に束縛 
しろ」を意味します。 

let のパターンマッチングの観点をよりはっきり確認するためにリスト 18-4 を考えてください。こ 
れは let でパターンを使用し、タプルを分配します。 

let ( x , y , z ) = (1, 2, 3); 

リスト 18-4: パターンを使用してタプルを分配し、3つの変数を一度に生成する 

ここでタプルに対してパターンをマッチさせています。 RllSt は値 （1, 2， 3) をパターン（ X ， y ， z ) 
と比較し、値がパターンに合致すると確認するので、1を x に、2を y に、3を z に束縛します。この 
タプルパターンを個別の3つの変数パターンが内部にネストされていると考えることもできます。 

パターンの要素数がタプルの要素数と一致しない場合、全体の型が一致せず、コンパイルエラーに 
なるでしょう。例えば、リスト 18-5 は、3要素のタプルを2つの変数に分配しようとしているとこ 
ろを表示していて、動きません。 

let ( x , y ) = (1, 2, 3); 

リスト 18-5: 変数がタプルの要素数と一致しないパターンを間違って構成する 

このコードのコンパイルを試みると、このような型エラーに落ち着きます： 

error [ E 0308] : mismatched types 
-- > src / main . rs :2:9 
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2 | let (X ， y) =(1 ， 2 ， 3); 

| aaaaaa expected a tuple with 3 elements, found one with 2 elements 

| (3 要素のタプルを予期したのに、 2 要素のタプルが見つかりました） 

I 

= note : expected type '({integer}, {integer}, tinteger})' 
found type 、し ， _)' 

タプルの値のうち l つ以上を無視したかったら、「パターンで値を無視する」節で見かけるように、 
_か..を使用できるでしょう。パターンに変数が多すぎるというのが問題なら、変数の数がタブルの 
要素数と一致するように変数を減らすことで、型を一致させることが解決策です。 

18.1.6 関数の引数 

関数の引数もパターンにできます。リスト 18-6 のコードは、型 i32 の x という引数1つを取る foo 
という関数を宣言していますが、これまでに馴染み深くなっているはずです。 

fn foo(x: i32) { 

//コードがここに来る 
// code goes here 

} 

リスト 18-6: 関数シグニチャが引数にパターンを使用している 

X の部分がパターンです！ let のように、関数の引数でパターンにタプルを合致させられるでしょ 
う。リスト 18-7 では、タプルを関数に渡したのでその中の値を分離しています。 

フアイル名： src / main.rs 

fn print_coordinates (& (x, y) : & (i32, i32)) { 

// 現在の位置： （{},{}) 

println! ("Current location : ({}, {})", x, y); 

} 

fn main() { 

let point = (3, 5); 

print_coordinates(&point); 

} 

リスト 18-7: タプルを分配する引数を伴う関数 

このコードは Current location: (3, 5) と出力します。値 &(3, 5) はパターン &(x, y) と合致す 
るので、 x は値3、 y は値 5 になります。 

また、クロージャの引数リストでも、関数の引数リストのようにパターンを使用することができま 
す。第13章で議論したように、クロージャは関数に似ているからです。 

この時点で、パターンを使用する方法をいくつか見てきましたが、パターンを使用できる箇所全部 
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で同じ動作をするわけではありません。パターンが論駁不可能でなければならない箇所もあります。 
他の状況では、論駁可能にもなり得ます。この2つの概念を次に議論します。 

18.2 論駁可能性：パターンが合致しないかどうか 

パターンには2つの形態があります：論駁可能なものと論駁不可能なものです。渡される可能性の 
あるあらゆる値に合致するパターンは、論駁不可能なものです。文 let x = 5; の x は一例でしょう。 
x は何にでも合致し、故に合致に失敗することがあり得ないからです。なんらかの可能性のある値に対 
して合致しないことがあるパターンは、論駿可能なものです。一例は、式 if let Some(x) = a_val_ue 
の Some(x) になるでしよう； a_val_ue 変数の値が Some ではなく、 None なら、 Some(x) パターンは合致 
しないでしょうから。 

関数の引数、 let 文、 for ループは、値が合致しなかったら何も意味のあることをプログラムが実 
行できないので、論駿不可能なパターンしか受け付けられません 〇 if let と while let 式は、定義に 
より失敗する可能性を処理することを意図したものなので、論駿可能なパターンのみを受け付けます: 
条件式の機能は、成功か失敗によって異なる振る舞いをする能力にあるのです。 

一般的に、論駁可能と論駁不可能なパターンの差異について心配しなくてもいいはずです；しかし 
ながら、 エラー メッセ ー ジで見かけた際に対応できるように、論駁可能性の概念に確かに慣れておく 
必要があります。そのような場合には、コードの意図した振る舞いに応じて、パターンかパターンを 
使用している構文を変える必要があるでしょう。 

コンパイラが論駁不可能なパターンを必要とする箇所で論駁可能なパターンを使用しようとした 
ら、何が起きるかとその逆の例を見ましょう。リスト 18-8 は let 文を示していますが、パターンに 
は Some (x) と指定し、論駁可能なパターンです。ご想像通りかもしれませんが、このコードはコンパ 
イルできません。 


let bome(.x; = some_option_value; 


リスト 18-8: let で論駁可能なパターンを使用しようとする 


some_option_value が None 値だったなら、パターン Some(x) に合致しないことになり、パターン 
が論駁可能であることを意味します。ですが、 let 文は論駁不可能なパターンしか受け付けられませ 
ん。 None 値に対してコードができる合法なことは何もないからです。コンパイル時にコンパイラは、 
論駁不可能なパターンが必要な箇所に論駿可能なパターンを使用しようとしたと文句を言うでしょう： 


error[E0005] : refutable pattern in local binding: None not covered 

(エラー： ローカル束縛に論駿可能なパターン ：' None 、がカパーされていません） 


I 

3 | let Some(x) 

| A A A A A A A 


=some_option_vaiue; 
pattern 'None' not covered 
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パターン Some(x) で全ての合法な値をカバーしなかった（できませんでした！）ので、コンパイラは 
当然、コンパイルエラーを生成します。 

論駁不可能なパターンが必要な箇所に論駁可能なパターンがある問題を修正するには、パターンを 
使用するコードを変えればいいのです： let の代わりに if let を使用できます。そして、パターンが 
合致しなかったら、コードは合法に継続する手段を残して、波括弧内のコードを飛ばすだけでしょう。 
リスト 18-9 は、リスト 18-8 のコードの修正方法を示しています。 

# let some_option_value: 0ptionc]32> = None ; 
if let Some^x ; = some_option_value { 
println! ("{}", x); 

} 

リスト 18-9: let ではなく 、 if let と論駁可能なパターンを含むブロックを使用する 

コードに逃げ道を与えました！このコードは完全に合法ですが、エラーを受け取らないで論駁不可 
能なパターンを使用することはできないことを意味します。リスト 18-10 のように、 X のような常に 
マッチするパターンを if let に与えたら、コンパイルできないでしよう。 

if let x = 5 { 

println! ("{}", x) ; 

}； 


リスト 18-10： if let で論駁不可能なパターンを使用してみる 

コンパイラは、論駁不可能なパターンと if let を使用するなんて道理が通らないと文句を言い 
ます： 

error * [E 016 2] : irrefutable i r- Let pattern 
( エラー：論駁不可能な if-let パターン） 

-- > < anon > :2:8 

I 

2 | if let x = 5 { 

| a irrefutable pattern 

このため、マッチアームは、論駁不可能なパターンで残りのあらゆる値に合致すべき最後のアーム 
を除いて、論駁可能なパターンを使用しなければなりません。コンパイラは、たった1つしかアーム 
のない match で論駁不可能なパターンを使用させてくれますが、この記法は特別有用なわけではな 
く、より単純な let 文に置き換えることもできるでしょう。 

今やパターンを使用すべき箇所と論駁可能と論駁不可能なパターンの違いを知ったので、パターン 
を生成するために使用できる全ての記法を講義しましょう。 
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2 

3 

なんでも 


let x =1; 
match x { 

1=> println ! (" one ") , 

2 => println ! (" two ") , 

3 => println ! (" three ") , 

_ => println ! (" anything ") , 

} 


この コードは、 x の値が 1 なので、 one を出力します。 この 記法は、コードが特定の具体的な値を 
得た時に行動を起こしてほしい時に有用です。 

18.3.2 名前付き変数にマッチする 

名前付き変数はどんな値にも合致する論駁不可能な パターン であり、この本の中で何度も使用し 
てきました。ですが、名前付き変数を match 式で使うと、厄介な問題があります。 match は新しいス 
コープを開始するので、 match 式内の パターンの 一部として宣言された変数は、あらゆる変数同様に 
match 構文外部の同じ名前の変数を覆い隠します。リスト 18-11 で、値 Some(5) の x という変数と値 
10 の変数 y を宣言しています。それから値 x に対して match 式を生成します。マッチ アームのパター 
ンと最後の println! を見て、このコードを実行したり、先まで読み進める前にこのコードが何を出 
力するか推測してみてください。 

フアイル名： src / main.rs 

rn mann() { 

let x = Some(5) ; 
let y =10; 

match x { 

// 50 だつたよ 

Some (50) => println! ("Got 50") , 

// マッチしたよ 

Some(y) => println! ("Matched, y = {:?}", 


18.3 ハターン記法 

本全体で、多くの種類のパターンの例を見かけてきました。この節では、パターンで合法な記法全 
てを集め、それぞれを使用したくなる可能性がある理由について議論します。 

18.3.1 リテラルにマッチする 

第6章で目撃したように、パターンを直接リテラルに合致させられます。以下のコードが例を挙げ 
ています： 


/ / / / 
/ / / / 


y ) ， 
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//規定のケース 

=> println! ("Default case, x = { : ?}" , x), 

} 

// 最後には x = {}, y = {} 

println! ("at the end: x = {:?}， y = {:?}", x, y); 

} 

リスト 18-11: シャドーイングされた変数 y を導入するアームのある match 式 

match 式を実行した時に起こることを見ていきましょう。最初のマッチアームのパターンは、 x の 
定義された値に合致しないので、コードは継続します。 

2 番目のマッチアームのパターンは、 Some 値内部のあらゆる値に合致する新しい y という変数を導 
入します。 match 式内の新しい スコープ 内にいるので、これは新しい y 変数であり、最初に値 10 で 
宣言した y ではありません。この新しい y 束縛は、 Some 内のあらゆる値に合致し、 x にあるものはこ 
れです。故に、この新しい y は、 x の中身の値に束縛されます。その値は 5 なので、そのアームの式 
が実行され、 Matched, y = 5 と出力されます。 

x が Some (5) ではなく None 値だったなら、最初の2つのアームのパターンはマッチしなかったの 
で、値はアンダースコアに合致したでしょう。アンダースコアのアームのパターンでは x 変数を導入 
しなかったので、その式の父は、まだシャドーイングされない外側の x のままです。この架空の場合、 
match は Default case, x = None と出力するでしよう。 

match 式が完了すると、スコープが終わるので、中の y のスコープも終わります。最後の println! 
は at the end: x = Some(5) , y = 10 を生成します。 

シャドーイングされた変数を導入するのではなく、外側の x と y の値を比較する match 式を生成す 
るには、代わりにマッチガード条件式を使用する必要があるでしょう。マッチガードについては、後 
ほど、「マッチガードで追加の条件式」節で語ります。 

18.3.3 複数のパターン 

match 式で|記法で複数のパターンに合致させることができ、これは Or を意味します。例えば、以 
下の コードは X の値を マッチアームに 合致させ、最初の マッチアームには or 選択肢があり、 X の値 
がその アームの どちらかの値に合致したら、その アームのコー ドが走ることを意味します： 

let x =1; 

match x { 

// 1 か 2 

1 | 2 => println ! ("one or two") , 

"3 

3 => println! ("three") , 

// なんでも 

_ => println! ("anything") , 

} 
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このコードは、 one or two を出力します。 

18.3.4 ... で値の範囲に合致させる 

.••記法により、限度値を含む値の範囲にマッチさせることができます。以下のコードでは、パター 
ンが範囲内のどれかの値に合致すると、そのアームが実行されます： 

let x = 5; 

match x { 

//1 から 5 まで 

1 ... 5 => pnntln ! ("one through five") , 

// それ以外 

_ => println! ("something else") , 

} 

x が1、2、3、 4 か 5 なら、最初のアームが合致します。この記法は、|演算子を使用して同じ考え 
を表現するより便利です； 1 ... 5 ではなく、 I を使用したら、 1I 2 I 3 I 4 I 5 と指定しなければ 
ならないでしょう。範囲を指定する方が遥かに短いのです。特に1から1000までの値と合致させた 
いとかなら！ 

範囲は、数値か char •値でのみ許可されます。コンパイラがコンパイル時に範囲が空でないことを確 
認しているからです。範囲が空かそうでないかコンパイラにわかる唯一の型が char か数値なのです。 
こちらは、 char * 値の範囲を使用する例です： 

let x = ' c ' ; 

1二 文字前半 

'a' ... 'j' => println! ("early ASCII letter") , 

// ASCII 文字後半 

'k' ... 'z' => println! ("late ASCII letter") , 

// それ以外 

_ => println! ("something else") , 

} 

コンパイラには c が最初のパターンの範囲にあることがわかり、 early ASCII letter と出力され 
ます。 


18.3.5 分配して値を分解する 

また、パターンを使用して構造体、 enum 、 タプル、参照を分配し、これらの値の異なる部分を使 
用することもできます。各値を見ていきましよう。 
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18.3.5.1 構造体を分配する 

リスト 18-12 は、 let 文でパターンを使用して分解できる2つのフィールド X と y のある Point 構 
造体を示しています。 

フアイル名： src / main.rs 

struct Point { 
x : i '32, 
y : i '32, 

} 

fn main () { 

let p = Point { x : 0， y : 7 }; 

let Point { x : a , y : b } = p ; 
assert _ eq ! (0, a ); 
assert _ eq ! (7, b ); 

} 

リスト 18-12: 構造体のフィールドを個別の変数に分配する 

このコードは、 p 変数の x と y フィールドの値に合致する変数 a と b を生成します。この例は、パ 
ターンの変数の名前は、構造体のフィールド名と合致する必要はないことを示しています。しかし、 
変数名をフィールド名と一致させてどの変数がどのフィールド由来のものなのか覚えやすくしたくな 
ることは一般的なことです。 

変数名をフィールドに一致させることは一般的であり 、' let Poi nt { x : x , y : y } = p ; と書くこ 
とは多くの重複を含むので、構造体のフィールドと一致するパターンには省略法があります：構造体 
のフィールドの名前を列挙するだけで、パターンから生成される変数は同じ名前になるのです。リス 
卜 18-13 は、リスト 18-12 と同じ振る舞いをするコードを表示していますが、 let パターンで生成さ 
れる変数は a と b ではなく、 x と y です。 

フアイル名： src / main.rs 

struct Point { 
x : 132, 

y : 1*32, 

} 

fn main () { 

let p = Point { x : 0, y : 7 }; 

let Point { x , y } = p ; 
assert _ eq ! (0, x ); 
assert _ eq ! (7, y ); 

} 
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リスト 18-13: 構造体フィールド省略法で構造体のフィールドを分配する 

このコードは、 p 変数の x と y フィールドに一致する変数 x と y を生成します。結果は、変数 x と 
y が p 構造体の値を含むというものです。 

また、全フィールドに対して変数を生成するのではなく、リテラル値を構造体パターンの一部にし 
て分配することもできます。そうすることで他のフィールドは分配して変数を生成しつつ、一部の 
フィールドは特定の値と一致するか確認できます。 

リスト 18-14 は、 Point 値を3つの場合に区別する match 式を表示しています： x 軸上の点 （y = 0 
ならそうなる)、 y 軸上の点 （x = 0)、あるいはどちらでもありません。 

フアイル名： src/main.rs 

# struct Point { 

# x : i '32, 

# y : i '32, 

# } 

# 

fn mann () { 

let p = Point { x : 0, y : 7 }; 


match p { 

// x 軸上の {} 

Point { x , y : 0 } => println! ("On the x axis at {}" , x ), 

// y 軸上の {} 

Point { x : 0, y } => println! ("On the y axis at {}" , y ), 

// どちらの軸上でもない：（{}，{}) 

Point { x , y } => println ! ( n 0 n neither axis : ({}, {})", x , y ), 



リスト 18-14: 分配とリテラル値との一致を 1 つのパターンで 

最初のアームは、 y フィールドの値がリテラル0と一致するならマッチすると指定することで、 x 軸 
上にあるどんな点とも一致します。このパターンはそれでも、このアームのコードで使用できる x 変 
数を生成します。 

同様に、2番目のアームは、 x フィールドが0ならマッチすると指定することで y 軸上のどんな点 
とも一致し、 y フィールドの値には変数 y を生成します。3番目のアームは何もリテラルを指定しな 
いので、それ以外のあらゆる Point に合致し、 x と y フィールド両方に変数を生成します。 

この例で、値 p は0を含む x の力で2番目のアームに一致するので、このコードは On the y axis 
at 7 と出力します。 
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18.3.5.2 enum を分配する 

例えば、第 6 章のリスト 6-5 で 0 ption < i 32> を分配するなどこの本の前半で enum を分配しまし 
た。明示的に触れなかった詳細の 1 つは、 enum を分配するパターンは、 enum 内に格納されてい 
るデータが定義されている手段に対応すべきということです。例として、リスト 18-15 では、リスト 
6-2 から Message enum を使用し、内部の値それぞれを分配するパターンを伴う match を書いてい 
ます。 


フアイル名： src/mam.rs 


enum Message { 

Quit , 

Move { x : i 32， y : i 32 }， 
Write ( String ) ， 

ChangeColor ( i 32 , i 32 , i 32 ) , 

} 


fn main () { 

let msg = Message : : ChangeColor (0, 160， 255); 


match msg { 

Message: : Quit => { 

// Quit 列 挙 子には分配すべきデータがない 

println ! ("The Quit variant has no data to destructure . ") 

}, 

Message :: Move { x , y } => { 
println ! ( 

// x 方向に {}、 y 方向に {} だけ動く 

"Move in the x direction {} and in the y direction {}" , 

x , 

y 

)； 

} 

// テキストメッセージ ： {} 

Message : : Write ( text ) => println! ("Text message : {}" , text ), 
Message : : ChangeColor ( r , g , b ) => { 
println ! ( 

// 色を赤 {}， 緑 {}， 青 {} に変更 

"Change the color to red {}， green {}， and blue {}" , 

g ? 

b 



リスト 18-15: 異なる種類の値を保持する enum の列挙子を分配する 
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このコードは 、 Change the color to red 0 ， green 160 ， blue 255 と出力します。試しに msg の 
値を変更して、他のアームのコードが走るところを確認してください。 

Message : : Quit のようなデータのない enum 列挙子については、それ以上値を分配することがで 
きません。リテラル Message : 値にマッチするだけで、変数はそのパターンに存在しません。 

Message : : Move のような構造体に似た enUITl の列挙子に ついては、 構造体と一致させるために指 
定するパターンと似たパターンを使用できます。列挙子の名前の後に波括弧を配置し、それから変数 
とともにフィールドを列挙するので、部品を分解してこのアームのコードで使用します。ここでは、 
リスト 18-13 のように省略形態を使用しています。 

1 要素タプルを保持する Message : : Write や、 3 要素タプルを保持する Message : : ChangeColor のよ 
うなタプルに似た enum の列挙子に ついて、 パターンは、タプルと一致させるために指定するパター 
ンと類似しています。パターンの変数の数は、マッチ対象の列挙子の要素数と一致しなければなりま 
せん。 


18.3.5.3 参照を分配する 

パターンとマッチさせている値に参照が含まれる場合、値から参照を分配する必要があり、パター 
ンに&を指定することでそうすることができます。そうすることで参照を保持する変数を得るのでは 
なぐ参照が指している値を保持する変数が得られます。このテクニックは、参照を走査するイテレー 
夕があるクロージャで特に役に立ちますが、そのクロージャで参照ではなく、値を使用したいです。 

リスト 18-16 の例は、ベクタの Point インスタンスへの参照を走査し、 x と y 値に簡単に計算を行 
えるように、参照と構造体を分配します。 

# struct Point { 

# x : i '32, 

# y : 132, 

# } 

# 

Let points = vec ![ 

Point { x : 0, y : 0 }, 

Point { x :1, y : 5 }, 

Point { x : 10， y : -3 }， 

]； 

let sum _ of _ squares : i 32 = points 
• iter () 

. map ( |&Point { x , y } | x x + y * y ) 

. sum (); 

リスト 18-16: 構造体への参照を構造体のフィールド値に分配する 

このコードは、値 135 を保持する変数 sum _ of_squares を返してきて、これは、 x 値と y 値を 2 乗 
し、足し合わせ、 points ベクタの Point それぞれの結果を足して1つの数値にした結果です 0 
&Point { X， y } に&が含まれていなかったら、型不一致エラーが発生していたでしょう。 iter ■は 
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そうすると、実際の値ではなく、ベクタの要素への参照を走査するからです。そのエラーはこんな見 
た目でしよう： 

error [ E 0308] : mismatched types 
-- > 

I 

14 | • map (丨 Point { x , y }| x ^ x + y ^ y ) 

| aaaaaaaaaaaa expected & Point , found struct ' Point ' 

I 

= note : expected type '& Point ' 
found type ' Point ' 

このエラーは、コンパイラがクロージャに & p 0 int と一致することを期待しているのに、 Point への 
参照ではなく、 Point 値に直接一致させようとしたことを示唆しています。 

18.3.5.4 構造体とタプルを分配する 

分配パターンをさらに複雑な方法で混ぜてマッチさせ、ネストすることができます。以下の例は、構 
造体とタプルをタブルにネストし、全ての基本的な値を取り出している複雑な分配を表示しています: 

# struct Point { 

# x : 132, 

# y : 1.32, 

# } 

# 

let (( feet , inches ), Point { x , y }) = ((3， 10)， Point { x : 3， y : -10 }); 

このコードは、複雑な型を構成する部品に分配させてくれるので、興味のある値を個別に使用でき 
ます。 

パターンで分配することは、構造体の各フィールドからの値のように、複数の値をお互いに区別し 
て使用する便利な方法です。 

18.3.6 パターンの値を無視する 

match の最後のアームのように、パターンの値を無視して実際には何もしないけれども、残りの全 
ての値の可能性を考慮する包括的なものを得ることは、時として有用であると認識しましたね。値全 
体やパターンの一部の値を無視する方法はいくつかあります：_パターンを使用すること（もう見か 
けました)、他のパターン内で_パターンを使用すること、アンダースコアで始まる名前を使用するこ 
と、••を使用して値の残りの部分を無視することです。これらのパターンそれぞれを使用する方法と 
理由を探究しましょう。 

18.3.6.1 _で値全体を無視する 

どんな値にも一致するけれども、値を束縛しないワイルドカードパターンとしてアンダースコア、_ 
を使用してきました。アンダースコア、_パターンは特に match 式の最後のアームとして役に立ちま 
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すが、関数の引数も含めてあらゆるパターンで使えます。リスト 18-17 に示したようにですね。 

フアイル名： src / main.rs 

fn foo (_: i 32， y : i 32) { 

// このコードは、 y 引数を使うだけです： {} 

println! ("This code only uses the y parameter : {}" , y ); 


fn main () { 

foo (3, 4); 

} 


リスト 18-17: 関数シグニチヤで _ を使用する 


このコードは、最初の引数として渡された値3を完全に無視し、 This code only uses the y 
parameter : 4 と出力します。 

特定の関数の引数が最早必要ないほとんどの場合、未使用の引数が含まれないようにシグニチャを 
変更するでしょう。関数の引数を無視することが特に有用なケースもあり、例えば、トレイトを実装 
する際、特定の型シグニチャが必要だけれども、自分の実装の関数本体では引数の1つが必要ない時 
などです。そうすれば、代わりに名前を使った場合のようには、未使用関数引数についてコンパイラ 
が警告することはないでしょう。 

18.3.6.2 ネストされた_で値の一部を無視する 

また、他のパターンの内部で_を使用して、値の一部だけを無視することもでき、例えば、値の一 
部だけを確認したいけれども、走らせたい対応するコードでは他の部分を使用することがない時など 
です。 リスト 18-18 は、設定の値を管理する責任を負ったコードを示しています。業務要件は、 ユー 
ザが既存の設定の変更を上書きすることはできないべきだけれども、設定を解除し、現在設定がされ 
ていなければ設定に値を与えられるというものです。 

let mut setting_value = Some (5) ; 
let new _ setting_value = Some (10) ; 

match ( setting _ value , new _ setting _ value ) { 

(Some し）， Some し）） => { 

// 既存の値の変更を上書きできません 

println ! (" Can't overwrite an existing customized value ") ; 

} 

_ => { 

setting_value = new _ setting _ value ; 

} 

} 

// 設定は {:?} です 

println! ("setting is {:?}", setting _ value ); 
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リスト 18-18: Some 内の値を使用する必要がない時に Some 列挙子と合致するパターンでアンダー 
スコアを使用する 


しの j 一 卜は、 Can’t overwrite an existing custom zed value 、 そし'!- setting is Some (5) 
と出力するでしょう。最初のマッチアームで、どちらの Some 列挙子内部の値にも合致させたり、使 
用する必要はありませんが、 setting _ value と new _ setting _ value が Some 列挙子の場合を確かに確 
認する必要があります。その場合、何故 sett " ing _ value を変更しないかを出力し、変更しません。 

2番目のア^ー ムの_パタ^ー ンで表現される他のあらゆる場合 （setti ng _ value と new_setti ng_value 
どちらかが None なら）には、 new _ setting _ value に setting _ value になってほしいです。 

また、1つのパターンの複数箇所でアンダースコアを使用して特定の値を無視することもできます。 
リスト 18-19 は、 5 要素のタプルで 2 番目と 4 番目の値を無視する例です。 


let numbers = (2， 4, 8,16, 32); 
match numbers { 

( first , third ， fifth ) => { 

// 何らかの数値： {}，{}, {} 

println! ("Some numbers : {}， {}， {}" , first , third , fifth ) 



リスト 18-19: タプルの複数の部分を無視する 

このコードは 、 Some numbers : 2, 8, 32と出力し、値 4 と 16 は無視されます。 


18.3.6.3 名前を_で始めて未使用の変数を無視する 
変数を作っているのにどこでも使用していなければ、バグかもしれないので コンパイ ラは通常、警 
告を発します。しかし時として、まだ使用しない変数を作るのが有用なこともあります。プロトタイ 
プを開発していたり、プロジェクトを始めた直後だったりなどです。このような場面では、変数名を 
アンダースコアで 始めることで、 コンパイ ラに未使用変数について警告しないよう指示することがで 
きます。リスト 18-20 で 2 つの未使用変数を生成していますが、このコードを実行すると、そのうち 
の1つにしか警告が出ないはずです。 

フアイル名： src / main.rs 

fn man n (.; { 

let _x = 5; 
let y =10; 

} 

リスト 18-20: アンダースコアで 変数名を始めて未使用変数警告が出るのを回避する 
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ここで、変数 y を使用していないことに対して警告が出ていますが、アンダースコアが接頭辞に 
なっている変数には、使用していないという警告が出ていません。 

_だけを使うのとアンダースコアで始まる名前を使うことには微妙な違いがあることに注意してく 
ださい。 _ x 記法はそれでも、値を変数に束縛する一方で、_は全く束縛しません。この差異が問題に 
なる場合を示すために、リスト 18-21 はエラーを提示するでしょう。 

/ / こんにちは！ 

let s = Some(Stri ng: : from ("Hello! ") ); 

if let Some し s) = s { 

//文字列が見つかりました 
println! ("found a string 11 ); 

} 

pr-intln! ("{:?}", s); 

リスト 18-21: それでも、アンダースコアで始まる未使用の変数は値を束縛し、値の所有権を奪う 
可能性がある 

それでも s 値は _s にムーブされ、再度 s を使用できなくするので、エラーを受け取るでしょう。で 
すが、アンダースコアを単独で使用すれば、値を束縛することは全くありません。 5 が_にムーブさ 
れないので、リスト 18-22 はエラーなくコンパイルできます。 

let s = Some(Stri ng: : from ("Hello! ") ); 

if let Some し ） =s { 

println! ("found a string 11 ); 

} 

pr-intln! ("{:?}", s); 

リスト 18-22: アンダースコアを使用すると、値を束縛しない 

このコードは、 s を何にも束縛しないので、ただ単に上手く動きます。つまり、ムーブされないの 
です。 

18.3.6.4 .•で値の残りの部分を無視する 

多くの部分がある値では、..記法を使用していくつかの部分だけを使用して残りを無視し、無視す 
る値それぞれにアンダースコアを列挙する必要性を回避できます。..パターンは、パターンの残りで 
明示的にマッチさせていない値のどんな部分も無視します。リスト 18-23 では、3次元空間で座標を 
保持する Point 構造体があります。 match 式で x 座標のみ処理し、 y と z フィールドの値は無視した 
いです。 


struct Point { 
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X ： 132, 

y : 1*32, 
z ： 1.32, 

} 

Let origin = Point { x : 0, v : 0, z : 0 j -; 
match origin { 

Point { x , .. } => println! ("x is {}" , x ), 

} 

リスト 18-23: ••で X 以外の Point のフィールド全てを無視する 

x 値を列挙し、それから••パターンを含んでいるだけです。これは、 y : _や z : _と列挙しなけれ 
ばいけないのに比べて、手っ取り早いです。特に1つや2つのフィールドのみが関連する場面で多く 
のフィールドがある構造体に取り掛かっている時には。 

• •記法は、必要な数だけ値に展開されます。リスト 18-24 は、タプルで••を使用する方法を表示 
しています。 

フ アイ ル名： src / main.rs 
fn mann () { 

let numbers = (2， 4, 8，16， 32); 

match numbers { 

( first ，.., last ) => { 

println! ("Some numbers : {}， {}" , first , last ); 

}， 

> 

> 

リスト 18-24: タプルの最初と最後の値にだけ合致し、他の値を無視する 

このコードにおいて、最初と最後の値は first と last に合致します。••は、途中のもの全部に合 
致し、無視します。 

しかしながら、..を使うのは明確でなければなりません。どの値がマッチしてどの値が無視される 
べきかが不明瞭なら、コンパイラはエラーを出します。リスト 18-25 は、••を曖昧に使用する例な 
ので、コンパイルできません。 

フ アイ ル名： src / main.rs 
fn mann () { 

let numbers = (2， 4, 8，16， 32); 

match numbers { 

(.., second , ..) => { 
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pnntln ! ("Some numbers : {}" , second ) 

}, 

} 

} 

リスト 18-25: • • を曖昧に使用しようとする試み 

この例をコンパイルすると、こんなエラーが出ます： 

error : .. can only be used once per tupie or tuple struct pattern 

( エラー：、 .. 、は、タプルやタプル構造体パターン 1 つにつき、 1 回しか使用できません） 

-- > src / main . rs :5:22 

I 

5 | い.， second ， . . ; => { 

| A A 

コンパイラが、 second の値に合致する前にタブルの幾つの値を無視し、それからそれによってさら 
に幾つの値を無視するかを決めることは不可能です。このコードは、2を無視し、 second に4を束縛 
し、それから8、16、32を無視したり、2と4を無視して second に8を束縛し、それから16と32 
を無視するなどを意味することもあるでしょう。変数名の second は、コンパイラにとってなんの特 
別な意味もなく、このように2箇所で••を使うのは曖昧なので、コンパイルエラーになります。 

18.3 .7 ref と ref mut でパターンに参照を生成する 

ref を使用して値の所有権がパターンの変数にムーブされないように、参照を生成することに目を 
向けましょう。通常、パターンにマッチさせると、パターンで導入された変数は値に束縛されます。 
Rust の所有権規則は、その値が match などパターンを使用しているあらゆる場所にムーブされるこ 
とを意味します。リスト 18-26 は、変数があるパターンとそれから match の後に値全体を println ! 
文で後ほど使用する match の例を示しています。このコードはコンパイルに失敗します。 robot_name 
値の一部の所有権が、最初の match アームのパターンの name 変数に移るからです。 

let robot_name = Some ( Stnng : : f rom ( M Bors ") ); 

match robot_name { 

// 名前が見つかりました ： {} 

Some ( name ) => println! ("Found a name : {}" , name ), 

None => (), 

} 

// r * obot_name は： {:?} 

println ! (" robot_name is : {:?}", robot _ name ); 

リスト 18-26: match アームパターンで変数を生成すると、値の所有権が奪われる 

robot name の一部の所有権が name にムーブされたので 、 robot name に最早所有権がないために、 
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match の後に pri ntln !で最早 robot_name を使用することは叶いません。 

このコードを修正するために、 Some (name) パターンに所有権を奪わせるのではなく、 robot_name 
のその部分を借用させたいです。パターンの外なら、値を借用する手段は、&で参照を生成すること 
だと既にご認識でしようから、解決策は Some (name) を Some(&name) に変えることだとお考えかもし 
れませんね。 

しかしながら、「分配して値を分解する」節で見かけたように、パターンにおける&記法は参照を 生 
成せず、値の既存の参照にマッチします。パターンにおいて&には既にその意味があるので、&を使 
用してパターンで参照を生成することはできません。 

その代わりに、パターンで参照を生成するには、リスト 18-27 のように、新しい変数の前に ref 
キーワードを使用します。 

let robot_name = Some(String: : f rom("Bors"; ); 

match robot_name { 

Some (ref name) => println! ("Found a name : {}" , name), 

None => (), 

} 

println! ("robot_name is : {:?}", robot_name); 

リスト 18-27: パターンの変数が値の所有権を奪わないように参照を生成する 

robot_name の Some 列挙子の値が match にムーブされないので、この例はコンパイルできます; 
match はムーブするのではなく、 robot_name のデータへの参照を取っただけなのです。 

パターンで合致した値を可変化できるように可変参照を生成するには、 & mut の代わりに ref mut を 
使用します。理由は今度も、パターンにおいて、前者は既存の可変参照にマッチするためにあり、新 
しい参照を生成しないからです。リスト 18-28 は、可変参照を生成するパターンの例です。 

let mut robot_name = Some(String: : rrom("Bors") ); 

match robot_name { 

// 別の名前 

Some (ref mut name) => ^name = String: : f rom("Another name") , 

None => (), 

} 

println! ("robot_name is : {:?}", robot_name); 

リスト 18-28： ref mut を使用して、パターンの一部として値への可変参照を生成する 

この例はコンパイルが通り、 robot_name is: Some("Another name") と出力するでしよう。 name 
は可変参照なので、値を可変化するためにマッチアーム内で*演算子を使用して参照外しする必要が 
あります。 
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18.3.8 マッチガー ドで追加の条件式 

マッチガ_ドは、 match アームのパターンの後に指定されるパターンマッチングとともに、その 
アームが選択されるのにマッチしなければならない追加の if 条件です。マッチガードは、1つのパ 
ターン単独でできるよりも複雑な考えを表現するのに役に立ちます。 

この条件は、パターンで生成された変数を使用できます。リスト 18-29 は、最初のアームにパター 
ン Some(x) と if x < 5 というマッチガードもある match を不しています 0 

let num = Some (4) ; 

match num { 

// 5 未満です： 

Some(x) if x < 5 => println! ("less than five: {}" , x), 

Some(x) => println! ("{}" , x), 

None => (), 

} 

リスト 18-29: パターンにマッチガードを追記する 

この例は、 less than five: 4 と出力します。 num が最初のアームのパターンと比較されると、 
Some( 4 ) は Some(x) に一致するので、マッチします。そして、マッチガードが x の値が 5 未満か確認 
し、そうなっているので、最初のアームが選択されます。 

代わりに num が Some (10) だったなら、最初のアームのマッチガードは偽になったでしょう。10は 
5未満ではないからです。 Rust はそうしたら2番目のアームに移動し、マッチするでしょう。2番目 
のアームにはマッチガードがなく、それ故にあらゆる Some 列挙子に一致するからです。 

パターン内で if x < 5 という条件を表現する方法はありませんので、マッチガードにより、この 
論理を表現する能力が得られるのです。 

リスト 18-11 において、マッチガードを使用すれば、パターンがシャドーイングする問題を解決で 
きると述べました。 match の外側の変数を使用するのではなく、 match 式のパターン内部では新しい 
変数が作られることを思い出してください。その新しい変数は、外側の変数の値と比較することがで 
きないことを意味しました。リスト 18-30 は、マッチガードを使ってこの問題を修正する方法を表示 
しています。 

フアイル名： src / main.rs 

fn mann() { 

let x = Some (5); 
let y =10; 

match x { 

Some(50) => println! ("Got 50") , 

Some(n) if n == y => println! ("Matched, n = {:?}", n) , 
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=> println! ("Default case , x = { : ?}" , x ), 

} 

println! ("at the end : x = {:?}, y = {:?}", x , y ); 

} 

リスト 18-30: マッチガードを使用して外側の変数と等しいか確認する 

このコードは今度は 、 Default case , x = Some (5) と出力するでしょう。 2 杳目のマッチアームの 
パターンは、外側の y を覆い隠してしまう新しい変数 y を導入せず、マッチガード内で外側の y を使 
用できることを意味します。外側の y を覆い隠してしまう Some ( y ) としてパターンを指定するので 
はなく、 Some ( n ) を指定しています。これにより、何も覆い隠さない新しい変数 n が生成されます。 
match の外側には n 変数は存在しないからです。 

マッチガードの if n == y はパターンではなく、故に新しい変数を導入しません。この y は、新し 
いシャドーイングされた y ではなく、外側の y であり、 n と y を比較することで、外側の y と同じ値 
を探すことができます。 

また、マッチガードで or 演算子の|を使用して複数のパターンを指定することもできます；マッチ 
ガードの条件は全てのパターンに適用されます。リスト 18-31 は、|を使用するパターンとマッチ 
ガードを組み合わせる優先度を示しています。この例で重要な部分は 、 if y は6にしか適用されない 
ように見えるのに 、 if y マッチガードが4、5、 そして 6に適用されることです。 

Let x = 4; 

let y = false ; 

match x { 

// はい 

4 | 5 | 6 if y 二〉 println ! (" yes ") , 

"いいえ 

=> println ! (" no ") , 

} 

リスト 18-31: 複数のパターンとマッチガードを組み合わせる 

マッチの条件は、 x の値が4、5、6に等しくかつ y が true の場合だけにアームがマッチすると宣 
言しています。このコードが走ると、最初のアームのパターンは x が4なので、合致しますが、マッ 
チガード if y は偽なので、最初のアームは選ばれません。コードは2番目のアームに移動して、こ 
れがマッチし、このプログラムは no と出力します。理由は、 if 条件が最後の値の6だけでなく、パ 
ターン全体4丨5丨6に適用されるからです。言い換えると、パターンと関わるマッチガードの優先 
度は、以下のように振る舞います： 

(4 | 5 | 6) i f y => ... 


以下のようにではありません: 
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4 | 5 | (6 ify ) 二〉... 

コードを実行後には、優先度の動作は明らかになります：マッチガードが|演算子で指定される値 
のリストの最後の値にしか適用されないなら、アームはマッチし、プログラムは yes と出力したで 
しょう。 

18.3.9 @ 束縛 

at 演算子（@)により、値を保持する変数を生成するのと同時にその値がパターンに一致するかを調 
ベることができます。リスト 18-32 は、 Message : : Hello の id フイールドが範囲3 ... 7にあるかを確 
かめたいという例です。しかし、 アームに 紐づいた コー ドで使用できるように変数 icLvariable に値 
を束縛もしたいです。この変数をフィールドと同じ、 id と名付けることもできますが、この例では異 
なる名前にします。 


enum Message { 

Hello { id : i 32 }, 

} 

let msg = Message :: Hello { id : 5 }; 
match msg { 

Message :: Hello { id : id _ van'able @ 3... 7 } => { 

// 範囲内の id が見つかりました ： {} 

println ! ("Found an id in range : {}" , id _ var * iable ) 

}, 

Message :: Hello { id : 10...12 } => { 

// 別の範囲内の id が見つかりました 
pnntln ! ("Found an id in another range ") 

}, 

Message :: Hello { id } => { 

// それ以外の id が見つかりました 

println! ("Found some other id : {}" , id ) 



@ を使用してテストしつつ、パターンの値に束縛する 

この例は 、 Found an id in range : 5 と出力します。範囲3 ... 7の前に id _ variab 1 e @と指定す 
ることで、値が範囲パターンに一致することを確認しつつ、範囲にマッチしたどんな値も捕捉してい 
ます。 

パターンで範囲しか指定していない2番目のアームでは、アームに紐づいたコードに id フィール 
ドの実際の値を含む変数はありません。 id フィールドの値は10、11、12だった可能性があるでしょ 
うが、そのパターンに来るコードは、どれなのかわかりません。パターンのコードは id フィールド 
の値を使用することは叶いません。 id の値を変数に保存していないからです。 
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範囲なしに変数を指定している最後のアームでは、確かにアームのコードで使用可能な値が id と 
いう変数にあります。理由は、構造体フィールド省略記法を使ったからです。しかし、このアームで 
id フィールドの値に対して、最初の2つのアームのようには、確認を行っていません：どんな値でも、 
このパターンに一致するでしょう。 

@を使用することで、値を検査しつつ、1つのパターン内で変数に保存させてくれるのです。 

18.4 まとめ 

Rust のパターンは、異なる種類のデータを区別するのに役立つという点でとても有用です。 match 
式で使用されると、コンパイラはパターンが全ての可能性を網羅しているか保証し、そうでなければ 
プログラムはコンパイルできません。 let 文や関数の引数のパターンは、その構文をより有用にし、値 
を分配して小さな部品にすると同時に変数に代入できるようにしてくれます。単純だったり複雑だっ 
たりするパターンを生成してニーズに合わせることができます。 

次の本書の末尾から2番目の章では、 Rust の多彩な機能の高度な視点に目を向けます。 
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高度な機能 


今までに、 Rust プログラミング言語の最もよく使われる部分を学んできました。第20章でもう1 
つ別のプロジェクトを行う前に、時折遭遇する言語の側面をいくつか見ましょう。この章は、 Rust を 
使用する際に知らないことに遭遇した時に参考にすることができます。この章で使用することを学ぶ 
機能は、かなり限定的な場面でしか役に立ちません。あまり頻繁には手を伸ばすことがない可能性は 
ありますが、 Rust が提供しなければならない機能全ての概要を確かに把握してもらいたいのです。 
この章で講義するのは： 

• Unsafe Rust : Rust の保証の一部を抜けてその保証を手動で保持する責任を負う方法 
• 高度なライフタイム：複雑なライフタイム状況の記法 

•高度なトレイト：関連型、デフォルト型引数、フルパス記法、スーパートレイト、トレイトに 
関連するニュータイプパターン 

• 高度な型：ニュータイプパターンについてもっと、型エイリアス、 never 型、動的サイズ型 
• 高度な関数とクロージャ：関数ボインタとクロージャの返却 

皆さんのための何かがある Rust の機能の盛大な儀式です！さあ、飛び込みましょう！ 

19.1 Unsafe Rust 

ここまでに議論してきたコードは全て、 Rust のメモリ安全保証がコンパイル時に強制されていま 
した。しかしながら、 Rust には、これらのメモリ安全保証を強制しない第2の言語が中に隠されて 
います：それは unsafe Rust と呼ばれ、普通の Rust のように動きますが、おまけの強大な力を与え 
てくれます。 

静的解析は原理的に保守的なので 、 unsafe Rust が存在します。コードが保証を保持しているかコ 
ンパイラが決定しようとする際、なんらかの不正なプログラムを受け入れるよりも合法なプログラム 
を拒否したほうがいいのです。コードは大丈夫かもしれないけれど、コンパイラにわかる範囲ではダ 
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メなのです！このような場合、 unsafe コードを使用してコンパイラに「信じて！何をしているか 
わかってるよ」と教えられます。欠点は、自らのリスクで使用することです： unsafe コードを誤って 
使用したら、 null ポインタ参照外しなどのメモリ非安全に起因する問題が起こることもあるのです。 

Rust に unsafe な分身がある別の理由は、根本にある コンピュータのハー ドウヱアが本質的に 
unsafe だからです。 Rust が unsafe な処理を行わせてくれなかったら、特定の仕事を行えないで 
しょう。 Rust は、低レベルな システム プログラミングを許可する必要があります。直接 0S と相互作 
用したり、独自の 0 S を書くことさえもそうです。低レベルな システム プログラミングに取り組むこ 
とは、言語の目標の 1 つなのです。 unsafe Rust でできることとその方法を探究しましょう。 

19.1.1 unsafe の強大な力 （ superpower) 

unsafe Rust に切り替えるには、 unsafe キーワードを使用し、それから unsafe コードを保持す 
る新しいブロックを開始してください。 safe Rust では行えない 4 つの行動を unsafe Rust では行 
え、これは unsafe superpowers と呼ばれます。その superpower には、以下の能力が含まれて 
います： 

• 生ポインタを参照外しすること 

• unsafe な関数やメソッドを呼ぶこと 

• 可変で静的な変数にアクセスしたり変更すること 

• unsafe なトレイトを実装すること 

unsafe は、借用チヱッカーや他の Rust の安全性チヱックを無効にしないことを理解するのは重要 
なことです： unsafe コードで参照を使用しても、チヱックはされます。 unsafe キーワードにより、こ 
れら 4 つの機能にアクセスできるようになり、その場合、コンパイラによってこれらのメモリ安全性 
は確認されないのです。 unsafe ブロック内でも、ある程度の安全性は得られます。 

また、 unsafe は、そのブロックが必ずしも危険だったり、絶対メモリ安全上の問題を抱えている 
ことを意味するものではありません：その意図は、プログラマとして unsafe ブロック内のコードがメ 
モリに合法的にアクセスすることを保証することです。 

人間は失敗をするもので、間違いも起きますが、これら 4 つの unsafe な処理を unsafe で注釈さ 
れたブロックに入れる必要があることで、メモリ安全性に関するどんな エラー も unsafe ブロック内 
にあるに違いないと知ります。 unsafe ブロックは小さくしてください；メモリのバグを調査するとき 
に感謝することになるでしょう。 

unsafe なコードをできるだけ分離するために、 unsafe なコードを安全な抽象の中に閉じ込め、安 
全な API を提供するのが最善です。これについては、後ほど unsafe な関数とメソッドを調査する際 
に議論します。標準ライブラリの一部は、検査された unsafe コードの安全な抽象として実装されて 
います 0 安全な抽象に unsafe なコードを包むことで、 unsafe が、あなたやあなたのユーザが unsafe 
コードで実装された機能を使いたがる可能性のある箇所全部に漏れ出ることを防ぎます。安全な抽象 
を使用することは、安全だからです。 
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4 つの unsafe な superpower を順に見ていきましょう。 unsafe なコー ドへの 安全なイ ン ター 
フェイスを提供する一部の抽象化にも目を向けます。 

19.1 .2 生ポインタを参照外しする 

第 4 章の「ダングリング参照」節で、コンパイラは、参照が常に有効であることを保証することに 
触れました。 unsafe Rust には参照に類似した生ポインタと呼ばれる 2 つの新しい型があります。参 
照同様、生ポインタも不変や可変になり得て、それぞれ * const T と * mut T と表記されます。このア 
スタリスクは、参照外し演算子ではありません；型名の一部です。生ポインタの文脈では、不変は、参 
照外し後に直接ボインタに代入できないことを意味します。 

参照やスマートポインタと異なり、生ポインタは： 

• 同じ場所への不変と可変なボインタや複数の可変なボインタが存在することで借用規則を無視 
できる 

• 有効なメモリを指しているとは保証されない 
• null の可能性がある 
• 自動的な片付けは実装されていない 

これらの保証を コンパイ ラに強制させることから抜けることで、保証された安全性を諦めて パ 
フォーマンスを 向上させたり、 Rust の保証が適用されない他の言語や ハー ドウヱアとの インターフェ 
イスの能力を得ることができます。 

リスト 19-1 は、参照から不変と可変な生ポインタを生成する方法を示しています。 

let mut num = 5; 

let rl=&num as ^const i 32 ; 
let r 2 = &mut num as *mut i 32; 

リスト 19-1: 参照から生ボインタを生成する 

このコードには unsafe キーワードを含めていないことに気付いてください。 Safe コードで生ポイ 
ンタを生成できます；もうすぐわかるように、 unsafe ブロックの外では、生ポインタを参照外しでき 
ないだけなのです。 

as を使って不変と可変な参照を対応する生ポインタの型にキャストして生ポインタを生成しまし 
た。有効であることが保証される参照から直接生ポインタを生成したので、これらの特定の生ポイン 
夕は有効であることがわかりますが、その前提をあらゆる生ポインタに敷くことはできません。 

次に、有効であることが確信できない生ポインタを生成します。リスト 19-2 は、メモリの任意の 
箇所を指す生ポインタの生成法を示しています。任意のメモリを使用しようとすることは未定義です: 
そのアドレスにデータがある可能性もあるし、ない可能性もあり、コンパイラがコードを最適化して 
メモリアクセスがなくなる可能性もあるし、プログラムがセグメンテーシヨンフォールトでエラーに 
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なる可能性もあります。通常、このようなコードを書くいい理由はありませんが、可能ではあります。 

let address = 0 x 012345 usize ; 
let r = address as ^-const i 32; 

リスト 19-2: 任意のメモリアドレスへの生ポインタを生成する 

safe コードで生ポインタを生成できるけれども、生ポインタを参照外しして指しているデータを読 
むことはできないことを思い出してください。リスト 19-3 では、 unsafe ブロックが必要になる参照 
外し演算子の*を生ボインタに使っています。 

let mut num = 5; 

let rl=&num as *const ]32; 
let r 2 = &mut num as ^-mut i 32 ; 

unsafe { 

println! ( M rl is : {}" , * rl ); 
println ! ( M r 2 is : {}" , * r 2); 

} 

リスト 19-3: unsafe ブロック内で生ポインタを参照外しする 

ボインタの生成は害を及ぼしません；無効な値を扱うことに落ち着く可能性のあるボインタが指し 
ている値にアクセスしようとする時のみです。 

また、リスト 19-1 とリスト 19-3 では、 num が格納されている同じメモリ上の場所を両方とも指す 
★ const i 32 と* mut i 32 の生ポインタを生成したことに注目してください。代わりに num への不変と 
可変な参照を生成しようとしたら、コードはコンパイルできなかったでしょう。 Rust の所有権規則に 
より、不変参照と可変参照を同時に存在させられないからです。生ポインタなら、同じ場所への可変 
なポインタと不変なポインタを生成でき、可変なポインタを通してデータを変更し、データ競合を引 
き起こす可能性があります。気を付けてください！ 

これらの危険がありながら、一体何故生ポインタを使うのでしょうか？主なユースケースの1つ 
は、次の節 「 unsafe な関数やメソッドを呼ぶ」で見るように、 C コードとのインターフェイスです。 
別のユースケースは、借用チェッカーには理解できない安全な抽象を構成する時です。 unsafe な関 
数を導入し、それから unsafe コードを使用する安全な抽象の例に目を向けます。 

19.1 .3 unsafe な関数やメソッドを呼ぶ 

unsafe ブロックが必要になる2畨目の処理は、 unsafe 関数の呼び出しです。 unsafe な関数や 
メソッドも見た目は、普通の関数やメソッドと全く同じですが、残りの定義の前に追加の unsafe が 
あります。この文脈での unsafe キーワードは、この関数を呼ぶ際に保持しておく必要のある要求が 
関数にあることを示唆します。コンパイラには、この要求を満たしているか保証できないからです。 
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unsafe ブロックで unsafe な関数を呼び出すことで、この関数のドキュメンテーションを読み、関数 
の契約を守っているという責任を取ると宣言します。 

こちらは、本体で何もしない dangerous という unsafe な関数です： 

unsare fn dangerous() {} 


unsare { 

dangerous(); 

} 

個別の unsafe ブロックで dangerous 関数を呼ばなければなりません。 unsafe ブロックなしで 
dangerous を呼ぼうとすれば、エラーになるでしよう： 


error* [ヒ t)133] : call to unsare function requires unsafe runction or block 
(エラー： unsafe 関数の呼び出しには、 unsafe な関数かブロックが必要です） 

-- > 

I 

4 | dangerous() : 

| aaaaaaaaaaa call to unsafe function 

dangerous への呼び出しの周りに unsafe ブロックを挿入することで、コ ンパ イラに関数のドキユ 
メンテーシヨンを読み、適切に使用する方法を理解したことをアサートし、関数の契約を満たしてい 
ると実証しました。 

unsafe 関数の本体は、実効的に unsafe ブロックになるので、 unsafe 関数内で unsafe な別の処 
理を行うのに、別の unsafe ブロックは必要ないのです。 

19.1 .3.1 unsafe コードに安全な抽象を行う 

関数が unsafe なコードを含んでいるだけで関数全体を unsafe でマークする必要があることには 
なりません。事実、安全な関数で unsafe なコードをラップすることは一般的な抽象化です。例とし 
て、なんらかの unsafe コードが必要になる標準ライブラリの関数 s P iit _ at _ mut を学び、その実装方 
法を探究しましょう。この安全なメソッドは、可変なスライスに定義されています：スライスを1つ 
取り、引数で与えられた添え字でスライスを分割して2つにします。リスト 19-4 は、 split _ at_mut 
の使用法を示しています。 

let mut v = vec ! [1, 2, 3 ， 4 ， 5 ， 6]; 

Let r = &mut v [•• 」 ； 

let (a, b) = r.split_at_mut(3); 

assert_eq! (a, &mut [1 ， 2 ， 3]); 
assert_eq! (b, &mut [4 ， 5 ， 6]); 


リスト 19-4: 安全な split_at_mut 関数を使用する 
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この関数を safeRust だけを使用して実装することはできません。試みは、リスト 19-5 のように 
なる可能性がありますが、コンパイルできません。簡単のため、 split _ at_mut をメソッドではなく関 
数として実装し、ジヱネリックな型 T ではなく、 i 32 のスライス用に実装します。 

fn split _ at _ mut ( slice : &mut [ i 32] , mid : usize ) -> (&mut [1.32 ]， &mut [ i 32]) { 
let len = slice . len (); 

assert! (mid <= len ); 

(&mut slice [.. mid ], 

&mut slice [ mid ••]) 

} 


リスト 19-5: safe Rust だけを使用した spiit_at_mut の未遂の実装 

この関数はまず、スライスの全体の長さを得ます。それから引数で与えられた添え字が長さ以下で 
あるかを確認してスライス内にあることをアサートします。このアサートは、スライスを分割する添 
え字よりも大きい添え字を渡したら、その添え字を使用しようとする前に関数がパニックすることを 
意味します。 

そして、 2 つの可変なスライスをタプルで返します： 1 つは元のスライスの最初から mid 添え字ま 
で、もう一方は、 mid からスライスの終わりまでです。 

リスト 19-5 のコードのコンパイルを 試みる と、エラーになるでしよう。 


error[E0499] : cannot borrow nce as mutable more than once at a time 
(エラー： 一度に 2 回以上、 '*slice' を可変で借用できません） 


6 


8 


(&mut since[..mid], 

- rirst mutable borrow occurs here 

&mut slice[mid••]) 

aaaaa second mutable borrow occurs here 
first borrow ends here 


Rust の借用チェッカーには、スライスの異なる部分を借用していることが理解できないのです；同 
じスライスから2回借用していることだけ知っています。2つのスライスが被らないので、スライス 
の異なる部分を借用することは、根本的に大丈夫なのですが、コンパイラはこれを知れるほど賢くあ 
りません。プログラマにはコードが大丈夫とわかるのに、コンパイラにはわからないのなら 、 unsafe 
コードに手を伸ばすタイミングです。 

リスト 19-6 は unsafe ブロック、生ポインタ、 unsafe 関数への呼び出しをして spl_i t_at_mut の 
実装が動くようにする方法を示しています。 

use std :: slice; 

fn split_at_mut(slice : &mut [i32] , mid: usize) -> (&mut [i32 ] ， &mut [i32]) { 
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let ien = snce . len (); 

let ptr = s nce . as _ mut _ ptr (); 

assert! (mid <= len ); 

unsafe { 

( slice : : from _ raw _ parts _ mut ( ptr , mid ), 

slice :: from _ raw _ parts _ mut ( ptr . offset(mid as isize) ,len - mid )) 



リスト 19-6: spiit _ at_mut 関数の実装で unsafe コードを使用する 

第 4 章の「スライス型」節から、スライスはなんらかのデータへのポインタとスライスの長さであ 
ることを思い出してください。 len メソッドを使用してスライスの長さを得て、 as _ mut_ptr メソッド 
を使用してスライスの生ポインタにアクセスしています。この場合、 i 32 値の可変スライスがあるの 
で、 as _ mut_ptr は型* mut i 32 の生ポインタを返し、これを変数 ptr に格納しました。 

mid 添え字がスライス内にあるかというアサートを残しています。そして、 unsafe コードに到達し 
ます： slice : : from _ raw _ parts_mut 関数は、生ポインタと長さを取り、スライスを生成します。この 
関数を使って、 ptr から始まり、 mid の長さのスライスを生成しています。それから ptr に mid を引 
数として offset メソッドを呼び出し、 mid で始まる生ポインタを得て、そのポインタと mid の後の 
残りの要素数を長さとして使用してスライスを生成しています。 

関数 sl_i ce : : f rom _ raw _ parts_mut は、 unsafe です。何故なら、生ポインタを取り、このポインタ 
が有効であることを信用しなければならないからです。生ボインタの offset メソッドも unsafe で 
す。オフセット位置もまた有効なポインタであることを信用しなければならないからです。故に、 
slice :: f rom _ raw _ parts_mut と offset を呼べるように、その呼び出しの周りに unsafe ブロックを 
置かなければならなかったのです。コードを眺めて mid が ten 以下でなければならないとするアサー 
卜を追加することで、 unsafe ブロック内で使用されている生ボインタが全てスライス内のデータへの 
有効なポインタであることがわかります。これは、受け入れられ、適切な unsafe の使用法です。 

できあがった split _ at_mut 関数を unsafe でマークする必要はなく、この関数を Safe Rust から 
呼び出せることに注目してください。 unsafe コードを安全に使用する関数の実装で、 unsafe コード 
への安全な抽象化を行いました。この関数がアクセスするデータからの有効なボインタだけを生成す 
るからです。 

対照的に、リスト 19-7 の slice :: from_ra W _parts_mut の使用は、スライスが使用されるとクラッ 
シュする可能性が高いでしょう。このコードは任意のメモリアドレスを取り、10,000要素の長さのス 
ライスを生成します： 

use std :: slice; 


let address = 0 x 012345 usize ; 
let r = address as ^.mut i 32 ; 
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let slice = unsare { 

slice : : from _ raw _ parts _ mut ( r , 10000) 

>； 


リスト 19-7: 任意のメモリアドレスからスライスを生成する 


この任意の場所のメモリは所有していなく、このコードが生成するスライスに有効な i32 値が含ま 
れる保証もありません。 slice を有効なスライスであるかのように使用しようとすると、未定義動作 
に陥ります。 


19.1 .3.2 extern 関数を使用して、外部のコードを呼び出す 

時として、自分の Rust コードが他の言語で書かれたコードと相互作用する必要が出てくる可能性が 
あります。このために、 Rust には extern というキーワードがあり、これは、 FFI(Foreign Function 
Interface: 外部関数インターフヱイス）の生成と使用を容易にします。 FFI は、あるプログラミング 
言語に関数を定義させ、異なる（外部の）プログラミング言語にそれらの関数を呼び出すことを可能に 
する方法です 

リスト 19-8 は、 C の標準ライブラリから abs 関数を統合するセットアップ方法をデモしています。 
extern ブロック内で宣言された関数は、常に Rust コードから呼ぶには unsafe になります。理由は、 
他の言語では、 Rust の規則や保証が強制されず、コンパイラもチヱックできないので、安全性を保証 
する責任はプログラマに降りかかるのです。 


ファイル名： src/main.rs 
extern "C" { 

fn abs(input: i32) -> i32 ; 

} 

fn main() { 
unsafe { 

// -3 の絶対値は、 C によると {} 

println! ("Absolute value of -3 according to C: {}" , abs(-3)); 



リスト 19-8: 他の言語で定義された extern 関数を宣言し、呼び出す 

extern "C" ブロック内で他の言語から呼び出した関数の名前とシグニチャを列挙します。 "C" の部 
分は、外部関数がどの ABI(application binary interface: アプリケーション•バイナリ•インター 
フェイス） を使用しているか定義します： ABI は関数の呼び出し方法をアセンブリレベルで定義しま 
す。" c ” ABI は最も一般的で C プログラミング言語の ABI に従っています。 
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19.1.3.3 他の言語から Rust の関数を呼び出す 

また、 extern を使用して他の言語に Rust の関数を呼ばせるインターフヱイスを生成すること 
もできます。 extern ブロックの代わりに、 extern キーワードを追加し、 fn キーワードの直前 
に使用する ABI を指定します。さらに、 #[ no _ mangle ] 注釈を追加して RliSt コンパイラに関 
数名をマングルしないように指示する必要もあります。マングルとは、コンパイラが関数に与 
えた名前を他のコンパイル過程の情報をより多く含むけれども、人間に読みにくい異なる名前 
にすることです。全ての言語のコンパイラは、少々異なる方法でマングルを行うので、 Rust の 
関数が他の言語で名前付けできるように、 Rust コンパイラの名前マングルをオフにしなけれ 
ばならないのです。 

以下の例では、共有ライブラリにコンパイルし、 C からリンクした後に call _ from _ c 関数を C 
コードからアクセスできるようにしています： 

# l _ no _ manaLe ] 

pub extern M C M rn call_rrom_c() { 

// C から Rust 関数を呼び出したばかり！ 

println ! ("Just called a Rust function from C! ") ; 

} 

この extern の使用法では、 unsafe は必要ありません。 

19.1.4 可変で静的な変数にアクセスしたり、変更する 

今までずっと、グローバル変数に ついて 語りませんでした。 グローバル 変数を Rust は確かにサ 
ポートしてい ますが 、 Rust の 所有権規則で問題になることもあります。2 つのスレッ ドが同じ可変な 
グローバル 変数に アクセスして いたら、 データ 競合を起こすこともあります。 

Rust では、 グローバル 変数は、 static (静的）変数と呼ばれます。 リスト 19-9 は、値として文字列 
スライスの ある静的変数の宣言例と使用を示しています。 

フアイル名： src / main.rs 

static HELLO_WORLD: &str = "Hello, world!"; 

fn main() { 

// 名前は ： {} 

println! ("name is: {}" , HELLO_WORLD); 

} 

リスト 19-9: 不変で静的な変数を定義し、使用する 

静的変数は、定数に似ています。定数については、第3章の「変数と定数の違い」節で議論しまし 
た。静的変数の名前は慣習で SCREAMING_SNAKE_CASE ( 直訳： 叫ぶスネークケース）になり、変数の型を 
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注釈しなければなりません。この例では &' static str です。静的変数は、 'static ライフタイムの参 
照のみ格納でき、これは、 Rust コンパイラがライフタイムを推量できることを意味します；明示的に 
注釈する必要はありません。不変で静的な変数にアクセスすることは安全です。 

定数と不変で静的な変数は、類似して見える可能性がありますが、微妙な差異は、静的変数の値は 
固定されたメモリアドレスになることです。値を使用すると、常に同じデータにアクセスします。一 
方、定数は使用される度にデータを複製させることができます。 

定数と静的変数の別の違いは、静的変数は可変にもなることです。可変で静的な変数にアクセスし 
変更することは、 unsafe です。リスト 19-10 は、 counter という可変で静的な変数を宣言し、アク 
セスし、変更する方法を表示しています。 

フアイル名： src / main.rs 

static mut COUNTER: u32 = 0; 

fn add_to_count(inc : u32) { 
unsafe { 

COUNTER += inc; 

} 

} 

fn main() { 

add_to_count(3); 

unsafe { 

println! ("COUNTER: {} ， ' ， COUNTER); 

} 

} 

リスト 19-10: 可変で静的な変数を読んだり、書き込むのは unsafe である 

普通の変数同様、 mut キーワードを使用して可変性を指定します。 COUNTER を読み書きするコードは 
どれ も、 unsafe ブロックになければなりません。 シングルス レッドなので、このコードは想定通り、 
コンパイル でき、 COUNTER: 3 と出力します。複数のスレッドに COUNTER にアクセスさせると、データ 
競合になる可能性が高いでしょう。 

グローバルに アクセス可能な可変なデータがあると、データ競合がないことを保証するのは難し 
くなり、そのため、 Rust は可変で静的な変数を unsafe と考えるのです。可能なら、コンパイラが、 
データが異なるスレッドからアクセスされることが安全に行われているかを確認するよう に、 第16 
章で議論した並行性テクニックとスレッド安全な スマート ポインタを使用するのが望ましいです。 

19.1 .5 unsafe なトレイトを実装する 

unsafe でのみ動く最後の行動は、 unsafe なトレイトを実装することです。少なくとも、1つのメ 
ソッドにコンパイラが確かめられないなんらかの不変条件があると、トレイトは unsafe になります。 
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trait の前に unsafe キーワードを追加し、トレイトの実装も unsafe でマークすることで、トレイト 
が unsafe であると宣言できます。リスト 19-11 のようにですね。 

unsafe trait Foo i 

// methods go here 

//メソッドがここに来る 

} 

unsafe impl Foo for i 32 { 

// method implementations go here 

// メソッドの 実装が ここに 来る 

} 

リスト 19-11: unsafe なトレイトを定義して実装する 

unsafe impt を使用することで、コンパイラが確かめられない不変条件を守ることを約束してい 
ます。 

例として、第 16 章の 「 Sync と Send トレイトで拡張可能な並行性」節で議論した Sync と Send マー 
カートレイトを思い出してください：型が完全に Send と Sync 型だけで構成されていたら、コンパイ 
ラはこれらのトレイトを自動的に実装します。生ポインタなどの Send や Sync でない型を含む型を実 
装し、その型を Send や Sync でマークしたいなら、 unsafe を使用しなければなりません。コンパイ 
ラは、型が スレッ ド間を安全に送信できたり、複数の スレッ ドから安全にアクセスできるという保証 
を保持しているか確かめられません；故に、そのチヱックを手動で行い、 unsafe でそのように示唆す 
る必要があります。 

19.1 .6 いつ unsafe コードを使用するべきか 

unsafe を使って議論したばかりの 4 つの行動（強大な力）のうちの 1 つを行うのは間違っていたり、 
認められさえもしないものではありません。ですが、 unsafe コードを正しくするのは、より巧妙なこ 
とでしょう。コンパイラがメモリ安全性を保持する手助けをできないからです。 unsafe コードを使用 
する理由があるなら、そうすることができ、明示的に unsafe 注釈をすることで問題が起きたら、そ 
の原因を追求するのが容易になります。 

19.2 高度なライフタイム 

第10章の「ライフタイムで参照を検証する」節で、参照をライフタイム引数で注釈し、コンパイ 
ラに異なる参照のライフタイムがどう関連しているかを指示する方法を学びました。全ての参照には 
ライフタイムがあるものの、ほとんどの場合、コンパイラがライフタイムを省略させてくれることも 
見ました。ここでは、まだ講義していないライフタイムの高度な機能を 3 つ見ていきます： 

• ライフタイム•サブタイピング：あるライフタイムが他のライフタイムより長生きすることを 
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保証する 

•ライフタイム境界：ジヱネリックな型への参照のライフタイムを指定する 

• トレイトオブジェクトのライフタイムの推論：コンパイラにトレイトオブジェクトのライフタ 
イムを推論させることと指定する必要があるタイミング 

19.2.1 ライフタイム■サブタイピングにより、あるライフタイムが他よりも長生き 
することを保証する 


ライフタイム-サブタイピング （lifetime subtyping ; 訳注：あえて訳すなら、ライフタイムの継承) 
は、あるライフタイムが他のライフタイムよりも長生きすべきであることを指定します。ライフタイ 
ム•サブタイピングを探究するために、パーサを書きたいところを想像してください。パース（訳注： 
parse ; 構文解析）中の文字列への参照を保持する context と呼ばれる構造を使用します。この文字列 
をパースし、成功か失敗を返すパーサを書きます。パーサは構文解析を行うために Context を借用す 
る必要があるでしょう。リスト 19-12 は、コードに必要なライフタイム注釈がないことを除いてこの 
パーサのコードを実装しているので、コンパイルはできません。 

ファイル名： src / lib.rs 


struct Context (&str) ; 

struct Parser { 

context : &Context, 

} 

impl Parser { 

fn parse(&self) -> Result< (), &str> { 
Err (&self. context.0[1..]) 



リスト 19-12: ライフタイム注釈なしでパーサを定義する 


コンパイラは Context の 文字列 スライスと Parser の Context への 参照に ライフタイム 引数を期待 
する ので、このコードをコンパイル すると、 エラーに 落ち着きます。 

簡単のため、 parse 関数は、 Result< () , &str> を返します。つまり、関数は成功時には何もせず、 
失敗時には、正しくパースできなかった文字列スライスの一部を返すということです。本物の実装は、 
もっとエラーの情報を提供し、パースが成功したら、構造化されたデータ型を返すでしょう。そのよ 
うな詳細を議論するつもりはありません。この例のライフタイムの部分に関係ないからです。 

このコードを単純に保つため、構文解析のロジックは何も書きません。ですが、構文解析ロジック 
のどこかで、非合法な入力の一部を参照するエラーを返すことで非合法な入力を扱う可能性が非常に 
高いでしょう；この参照が、ライフタイムに関連してこのコード例を面白くしてくれます。パーサの 
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ロジックが、最初のバイトの後で入力が不正だった振りをしましょう。最初のバイトが合法な文字境 
界になければ、このコードはパニックする可能性があることに注意してください；ここでも、例を簡 
略化して関連するライフタイムに集中しています。 

このコードをコンパイルできるようにするには、 Context の文字列スライスと Parser の Context 
への参照のライフタイム引数を埋める必要があります。最も率直な方法は、リスト 19-13 のように、 
全ての箇所で同じライフタイム名を使用することです。第10章の「構造体定義のライフタイム注釈」 
節から 、 struct Context <’ a>、struct Parser <’ a >、 impl < ’ a > それぞれが新しいライフタイム引数 
を宣言することを思い出してください。全部の名前が偶然一致しましたが、この例で宣言された3つ 
のライフタイム引数は、関連していません。 

ファイル名： src / lib.rs 

struct Context く ， a> (& 1 a str ) ; 

struct Parser <' a > { 

context : &'a Context く ， a >, 

} 

impl < ' a > Parser く ， a > { 

fn parse (& self ) -> Result < (), & str > { 

Err (& self . context .0[1..]) 

} 

} 

リスト 19-13: Context と Parser の全参照をライフタイム引数で注釈する 

このコードは、単純にうまくコンパイルできます。コンパイラに Parser はライフタイム， a の 
Context への参照を保持し、 Context は Parser の Context への参照と同じ期間生きる文字列スライ 
スを保持していると指示しています。 Rust コンパイラのエラーメッセージは、これらの参照にライフ 
タイム引数が必要であることを述べていて、今ではライフタイム引数を追加しました。 

次にリスト 19-14 では、 Context のインスタンスを1つ取り、 Parser を使ってその文脈をパース 
し、 parse が返すものを返す関数を追加します。このコードはあまり動きません。 

ファイル名： src / lib.rs 

fn parse_context ( context : Context ) -> Resu Lt < (), & str > i . 

Parser { context : &context }. parse () 

} 

リスト 19-14： Context を取り、 Parser を使用する parse _ context 関数を追加する試み 

parse . context 関数を追加してコードをコンパイルしようとすると、2つ冗長なエラーが出ます： 

error [ E 0597] : borrowed value does not live Long enough 
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(エラー： 借用された値は十分長生きしません） 
-- > src/lib.rs:14:5 


14 

15 


Parser { context : &context }.parseu 

AAAAAAAAAAAAAAAAAAAAAAAAAAAA d06S PlOt "L"ive "LOflg GPIOU §h 


- temporary value only lives untiL here 


note : borrowed value must be valid for the anonymous lifetime #1 defined on the 
function body at 13:1... 

(注釈：借用された値は、 13:1 の関数本体で定義された 1 番目の匿名のライフタイムに有効 
でなければなりません） 

-- > src/lib.rs:13:l 

I 

13 | / fn parse_context(.context : Context) -> Result< u > &str> { 

14 | | Parser { context : &context }.parse() 

15 | | } 

I l- A 

error[E0597] : 'context' does not live long enough 
--> src/lib.rs:14:24 

I 

14 | Parser { context: &context }.parse() 

| aaaa ハ aa does not live long enough 

15 | } 

| - borrowed value only lives until here 

I 

note : borrowed value must be valid for the anonymous lifetime #1 defined on the 
function body at 13:1... 

--> src/lib.rs:13:l 

I 

13 | / fn parse_context(context : Context) -> Result<(), &str> { 

14 | | Parser { context : &context }.parse() 

15 | | } 


これらのエラーは、生成された Parser インスタンスと context 引数が parse_context 関数の最後 
までしか生きないと述べています。しかし、どちらも関数全体のライフタイムだけ生きる必要があり 
ます。 

言い換えると、 Parser と context は関数全体より長生きし、このコードの全参照が常に有効であ 
るためには、関数が始まる前や、終わった後も有効である必要があります。生成している Parser と 
context 引数は、関数の終わりでスコープを抜けます。 parse_context が context の所有権を奪って 
いるからです。 

これらのエラーが起こる理由を理解するため、再度リスト 19-13 の定義、特に parse メソッドのシ 
グニチヤの参照を観察しましょう： 


fn parse (& self ) -> Result < () , & str > { 
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省略規則を覚えていますか？省略するのではなく、参照のライフタイムを注釈するなら、シグニ 
チャは以下のようになるでしょう： 

fn parse <' a>(&'a self ) -> Result < (), &'a str > { 

要するに、 parse の戻り値のエラー部分は、 Parser インスタンスのライフタイムと紐づいたライフ 
タイムになるのです （parse メソッドシグニチャの &self のライフタイム)。それは、理に適っていま 
す：返却される文字列スライスは、 Parser に保持された Context インスタンスの文字列スライスを参 
照していて、 Parser 構造体の定義は、 Context への参照のライフタイムと Context が保持する文字列 
スライスのライフタイムは同じになるべきと指定しています。 

問題は、 par * se_context 関数は、 parse から返却される値を返すので、 par * se_context の民り値の 
ライフタイムも、 Parser ■のライフタイムに紐づくことです。しかし、 parse_context 関数で生成され 
た Parser インスタンスは、関数の終端を超えて生きることはなく（一時的なのです)、 context も関数 
の終端でスコープを抜けるのです ( parse_context が所有権を奪っています)〇 

コンパイラは、私たちが、関数の終端でスコープを抜ける値への参照を返そうとしていると考えま 
す 0 全ライフタイムを同じライフタイム引数で注釈したからです。注釈は、コンパイラに Context が 
保持する文字列スライスのライフタイムは、 Parser が保持する Context への参照のライフタイムと 
一致すると指示しました。 

parse_context 関数には、 parse 関数内で返却される文字列スライスが Context と Parser より長 
生きし、 parse_context が返す参照が Context や Parser ではなく、文字列スライスを参照すること 
はわかりません。 

parse の実装が何をするか知ることで、 parse の民り値が Parser インスタンスに紐づく唯一の理由 
が、 Parser インスタンスの Context 、 弓 I いては文字列スライスを参照していることであることを把 
握します。従って、 par * se_context が気にする必要があるのは、本当は文字列スライスのライフタイ 
ムなのです。 Context の文字列スライスと Parse 「の Context への参照が異なるライフタイムになり、 
parse_context の民り値が Context の文字列スライスのライフタイムに紐づくことをコンパイラに教 
える方法が必要です。 

まず、試しに Parse 「と Context に異なるライフタイム引数を与えてみましょう。リスト 19-15 の 
ようにですね〇ライフタイム引数の名前として、と •(： を使用して、どのライフタイムが Context の 
文字列スライスに当てはまり、どれが Pa rse r •の Context への参照に当てはまるかを明確化します 0 
この解決策は、完全には問題を修正しませんが、スタート地点です。コンパイルしようとする時にこ 
の修正で十分でない理由に目を向けます。 

ファイル名： src / lib.rs 

struct Context く ， s > (&丨 s str ) ; 

struct Parser <' c , ' s > { 

context : &' c Context く ， s >, 

} 
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■impl< ' c, ' s> Parser< ' c , ' s> { 

fn parse(&self) -> Result< (), &'s str> { 
Err (&self. context.0[1..]) 



fn parse_context(context : Context) -> Result< (), &str> { 
Parser { context : &context }.parse() 

} 


リスト 19-15: 文字列スライスと Context への参照に異なるライフタイム引数を指定する 


参照のライフタイム全部をリスト 19-13 で注釈したのと同じ箇所に注釈しました。ですが今回は、 
参照が文字列スライスか Context に当てはまるかによって異なる引数を使用しました。また、 parse 
の戻り値の文字列スライス部分にも注釈を追加して、 Context の文字列スライスのライフタイムに当 
てはまることを示唆しました。 

今 コンパイルを 試みると、以下のようなエラーになります： 


error[E 049 1] : in type &'c Context く ， s> , reference has a longer liretime than 
the data it references 

(エラー： 型 ' & 1 c Cotnext く ’s> 、 において、参照のライフタイムが参照先のデータよりも長 
くなっています） 

-- > src/lnb.rs:4:5 

I 

4 | context : &'c Context く ， s>, 


note : the pointer is vand for the lifetime 'c as denned on the struct at 3:1 

(注釈：ポインタは 3:1 の構造体で定義されたように、ライフタイム 4 の間有効です） 

-- > src / lnb . rs :3:1 

I 

3 | / struct Parser <' c , ' s > { 

4 | | context : &'c Context く ， s >, 

5 | | } 

I l- A 

note : but the referenced data is only valid for the Lifetime 's as defined on 
the struct at 3:1 

(注釈：しかし、参照されたデータは、 3:1 の構造体で定義されたように、ライフタイム 4 
の間だけ有効です） 

-- > src / lnb . rs :3:1 


3 | / struct Parser<'c , 's> { 

4 | | context : &'c Context く ， s>, 

5 11} 


コンパイラは、 'c と、の間になんの関連性も知りません。合法であるために、 Context でライフタ 
イム ' s と参照されたデータは、制限され、ライフタイム ' c の参照よりも長生きすることを保証する 
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必要があります。 ' s が4より長くないと、 Context への参照は合法ではない可能性があるのです。 

さて、この節の要点に到達しました： Rust の機能、ライフタイム■サブタイピングは、あるライフ 
タイム引数が、少なくとも他のライフタイムと同じだけ生きることを指定します。ライフタイム引数 
を宣言する山カッコ内で、通常通りライフタイム ' a を宣言し、 ’ b を’ b : ’ a 記法を使用して宣言する 
ことで、 1 a と少なくとも同じ期間生きるライフタイム ' b を宣言できます。 

Parser の定義で、 1 s (文字列スライスのライフタイム）が少なくとも 1 c ( Context への参照のライフ 
タイム）と同じ期間だけ生きると、保証することを宣言するには、ライフタイム宣言を以下のように 
変更します： 

ファイル名： src / lib.rs 

# struct Context <' a>(&'a str ) ; 

# 

struct Parser <' c , ' s : ' c > { 
context : &' c Context く ， s >, 

} 

これで Parser の Context への参照と Context の文字列スライスへの参照のライフタイムは、違う 
ものになりました；文字列スライスのライフタイムが Context への参照よりも長いことを保証したの 
です。 

非常に長くぐにゃぐにゃした例でしたが、この章の冒頭で触れたように、 Rust の高度な機能は、非 
常に限定的です。この例で解説した記法は、あまり必要になりませんが、そのような場面では、何か 
を参照し、それに必要なライフタイムを与える方法を知っているでしょう。 

19.2.2 ジヱネリックな型への参照に対するライフタイム境界 

第10章の「トレイト境界」節で、ジェネリックな型にトレイト境界を使用することを議論しまし 
た。また、ジェネリックな型への制限としてライフタイム引数を追加することもできます；これはラ 
イフタイム境界と呼ばれます。ライフタイム境界は、コンパイラが、ジヱネリックな型の中の参照が 
参照先のデータよりも長生きしないことを確かめる手助けをします。 

例として、参照のラッパの型を考えてください。第15章の 「 RefCell < T > と内部可変性パターン」節 
から RefCell < T > 型を思い出してください： borrow と borrow_mut メソッドがそれぞれ、 Ref と RefMut 
を返します。これらの型は、実行時に借用規則を追いかける参照に対するラッパです。 Ref 構造体の 
定義をリスト 19-16 に今はライフタイム境界なしで示しました。 

ファイル名： src / lib.rs 

struct Ref く ， a , T>(&'a T ); 


リスト 19-16: ライフタイム境界なしでジェネリックな型への参照をラップする構造体を定義する 
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明示的にジェネリック引数 T と関連してライフタイム ' a を制限しないと、ジェネリックな型 T がど 
れだけ生きるのかわからないので、 コンパイ ラはエラーにします： 

error[E0309] : the parameter type T' may not live Long enough 
(エラー：パラメータ 型の ' T' は十分長生きしないかもしれません） 

-- > src / lib . rs : l :19 

I 

1 | struct Ref く ， a ， T>(&'a T); 

| A A A A A A 

I 

= heLp : consider adding an explicit lifetime bound ' T : ' a '... 

( 助言：明示的なライフタイム境界 ' T: を追加することを考慮してください） 

note : ...so that the reference type &'a T' does not outlive the data it points 
at 

( 注釈：そうすれば、参照型の T' が、指しているデータよりも長生きしません） 

-- > src / lib . rs : 1:19 

I 

1 | struct Ref く ， a ， T>(&'a T); 

| A A A A A A 

T はどんな型にもなるので、 T が参照や1つ以上の参照を保持する型になることもあり、その個々 
の参照が独自のライフタイムになることもあるでしょう。コンパイラは、 T が ' a と同じだけ生きるこ 
とを確信できません。 

幸運なことに、この場合、エラーがライフタイム境界を指定する方法について役に立つアドバイス 
をくれています： 

consider adding an explicit nfetime bound f : 'a so that the reference type 
'a T' does not out Live the data it points at 

リスト 19-17 は、ジェネリックな型 t を宣言する時にライフタイム境界を指定することで、このア 


ドバイスを適用する方法を示しています。 


struct Ref<’a ， T: 1 a>(& 1 a T); 

リスト 19-17： T にライフタイム境界を追加して T のどんな参照も少なくとも、 ' a と同じだけ生き 
ると指定する 

このコードはもう コンパイルで きます。 T : ' a 記法により、 T はどんな型にもなり得ますが、何か 
参照を含んでいるのなら、その参照は少なくとも、 ’ a と同じだけ生きなければならないと指定してい 
るからです。 

この問題をリスト 19-18 の StaticRef 構造体の定義で不したように、 T に 1 stati c ライフタイム境 
界を追加し、異なる方法で解決することもできます。これは、 T に何か参照が含まれるなら、 'static 
ライフタイムでなければならないことを意味します。 

struct StaticRef<T: 1 static〉 （&' static T); 
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リスト 19-18： T に 1 static ライフタイム境界を追加して T を 1 static 参照だけがあるか参照なしの 
型に制限する 

'stati c は、参照がプログラム全体と同じだけ生きなければならないことを意味するので、何も参 
照を含まない型は、全ての参照がプログラム全体と同じだけ生きるという基準を満たします（参照が 
ないからです)。借用チヱッカーが、参照が十分長生きしないと心配することに関しては、参照が何も 
ない型と永久に生きる参照がある型を現実的に区別できません：どちらも、参照が参照先のライフタ 
イムよりも短いか決定することに関しては同じです。 

19.2.3 トレイトオブジェクトライフタイムの推論 

第17章の「トレイトオブジェクトで異なる型の値を許容する」節で、参照の背後のトレイトから 
構成され、ダイナミック•ディスパッチを使用できるトレイトオブジェクトを議論しました。まだ、 
トレイトオブジェクトのトレイトを実装する型が、独自のライフタイムだった時に何が起きるか議論 
していません。トレイト Red と構造体 Ball があるリスト 19-19 を考えてください。 Ball 構造体は参 
照を保持し（故にライフタイム引数があり）、トレイト Red を実装もしています。 BaVL のインスタンス 
を Box < Red > として使用したいです。 

フアイル名： src / main.rs 

trait Red { } 

struct Ball く ， a > { 

diameter : &' a i 32 , 

} 

impl < ' a > Red for Ball く , a > { } 

fn main () { 

let num = 5; 

let obj = Box :: new ( Ball { diameter : &num }) as Box < Red > ; 

} 


リスト 19-19: トレイトオブジェクトでライフタイム引数のある型を使用する 


明示的に obj に関連するライフタイムを注釈していないものの、このコードはエラーなくコンパイ 
ルできます。ライフタイムとトレイトオブジェクトと共に働く規則があるので、このコードは動くの 
です： 

• トレイトオブジェクトのデフオルトのライフタイムは、 ' static 。 

• &' a Trait や& 1 a mut Trait に関して、トレイトオブジェクトのデフオルトのライフタイムは、 
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•単独の T : ' a 節について、トレイトオブジェクトのデフォルトのライフタイムは、， a 。 
•複数の T : ' a のような節について、デフォルトのライフタイムはない；明示しなければなら 
ない。 

明示しなければならない時、 Box < Red > のようなトレイトオブジェクトに対して、参照がプログラ 
ム全体で生きるかどうかにより、記法 Box<Red + 1 static > か Box<Red + 1 a > を使用してライフタイ 
ム境界を追加できます。他の境界同様、ライフタイム境界を追記する記法は、型の内部に参照がある 
Red トレイトを実装しているものは全て、トレイト境界に指定されるライフタイムがそれらの参照と 
同じにならなければならないことを意味します。 

次は、トレイトを管理する他の一部の高度な機能に目を向けましょう。 

19.3 高度なトレイト 

最初にトレイトについて講義したのは、第10章の「トレイト：共通の振る舞いを定義する」節でし 
たが、ライフタイム同様、より高度な詳細は議論しませんでした。今や、 Rust に詳しくなったので、 
核心に迫れるでしょう。 

19.3.1 関連型でトレイト定義においてプレースホルダーの型を指定する 

関連型は、トレイトのメソッド定義がシグニチャでプレースホルダーの型を使用できるように、卜 
レイトと型のプレースホルダーを結び付けます。トレイトを実装するものがこの特定の実装で型の位 
置に使用される具体的な型を指定します。そうすることで、なんらかの型を使用するトレイトをトレ 
イトを実装するまでその型が一体なんであるかを知る必要なく定義できます。 

この章のほとんどの高度な機能は、稀にしか必要にならないと解説しました。関連型はその中間に 
あります：本の他の部分で説明される機能よりは使用されるのが稀ですが、この章で議論される他の 
多くの機能よりは頻繁に使用されます。 

関連型があるトレイトの一例は、標準ライブラリが提供する Iterator トレイトです。その関連型 
は Item と名付けられ、 Iterator トレイトを実装している型が走査している値の型の代役を務めます。 
第 13 章の 「 Iterator トレイトと next メソッド」節で、 Iterator トレイトの定義は、リスト 19-20 
に示したようなものであることに触れました。 


pub trait Iterator { 
type Item ; 

fn next (&mut self ) -> Option < Self :: Item >; 


リスト 19-20: 関連型 Item がある Iterator トレイトの定義 
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型 Item はプレースホルダー型で next メソッドの定義は、型 Option く Self : : Item > の値を返すこと 
を示しています。 Iterator トレイトを実装するものは、 Item の具体的な型を指定し、 next メソッド 
は、その具体的な型の値を含む Option を返します。 

関連型は、ジヱネリクスにより扱う型を指定せずに関数を定義できるという点でジヱネリクスに似 
た概念のように思える可能性があります。では、何故関連型を使用するのでしょうか？ 

2つの概念の違いを第13章から Counter 構造体に Iterator * トレイトを実装する例で調査しましょ 
う。リスト 13-21 で、 Item 型は U 32 だと指定しました： 

ファイル名： src / lib.rs 


impl Iterator for Counter i 
type Item = u 32 ; 

fn next (&mut self ) -> Option < Self :: Item > { 

// --snip 

この記法は、ジェネリクスと比較可能に思えます。では、何故単純にリスト 19-21 のように、 
Iterator トレイトをジェネリクスで定義しないのでしようか？ 


oub trait Iterator < T > { 

fn next (&mut self ) -> Option < T >; 

} 

ジェネリクスを使用した架空の Iterator トレイトの定義 

差異は、リスト 19-21 のようにジェネリクスを使用すると、各実装で型を注釈しなければならない 
ことです； Iterator < String > for Counter や他のどんな型にも実装することができるので、 Counter 
の Iterator の実装が複数できるでしょう。換言すれば、トレイトにジヱネリックな引数があると、毎 
回ジェネリックな型引数の具体的な型を変更してある型に対して複数回実装できるということです。 
Counter に対して next メソッドを使用する際に、どの Iterator の実装を使用したいか型注釈をつけ 
なければならないでしょう。 

関連型なら、同じ型に対してトレイトを複数回実装できないので、型を注釈する必要はありません。 
関連型を使用する定義があるリスト 19-20 では、 Item の型は1回しか選択できませんでした。1つ 
しか impl Iterator for Counter がないからです。 Counter に next を呼び出す度に、 u 32 値のイテ 
レータが欲しいと指定しなくてもよいわけです。 

19.3.2 デフオルトのジェネリック型引数と演算子オーバーロード 

ジェネリックな型引数を使用する際、ジェネリックな型に対して規定の具体的な型を指定でき 
ます。これにより、規定の型が動くのなら、トレイトを実装する側が具体的な型を指定する必要を 
排除します。ジェネリックな型に規定の型を指定する記法は、ジェネリックな型を宣言する際に 
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<PlaceholderType=ConcreteType> で 9 ~〇 

このテクニックが有用になる場面の好例が、演算子オーバーロードです。演算子オーバーロードと 
は、特定の状況で演算子 （+ など）の振る舞いをカスタマイズすることです。 

Rust では、独自の演算子を作ったり、任意の演算子を オーバーロード することはできません。 しか 
し、演算子に紐づいたトレイトを実装することで std :: ops に列挙された処理と対応するトレイトを 
オーバーロードで きます。例えば、リスト 19-22 で+演算子を オーバーロードして 2 つの Point イ 
ンスタンスを足し合わせています。 Point 構造体に Add トレイトを実装することでこれを行なってい 
ます。 


フアイル名： src / main.rs 


use std :: ops :: Add ; 

# [ derive ( Debug ， PartiolEq )] 
struct Point { 
x: i32, 
y ： 1.32, 


impl Add for Point { 

type Output = Point; 


fn add (self , other: Point) -> Point { 
Point { 

x: self .x + other.x, 
y : self .y + other.y, 



fn main() { 

assert_eq! (Point { x : 1,y: 0 
Point { x: 3, y: 3 


} 


} + 
})； 


Point { x: 2, y: 3 }, 


リスト 19-22: Add トレイトを実装して Point インスタンス用に + 演算子をオーバーロードする 

add メソツドは 2 つの Point イ ンスタンスの x 値と 2 つの Point イ ンスタンスの y 値を足します。 
Add トレイトには、 add メソッドから返却される型を決定する Output という関連型があります。 

このコードの規定のジェネリック型は、 Add トレイト内にあります。こちらがその定義です： 

trait Add く RHS=Self> { 
type Output; 

fn add (self , rhs : RHS) -> Self::Output; 

} 
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このコードは一般的に馴染みがあるはずです：1つのメソッドと関連型が1つあるトレイトです。 
新しい部分は、 RHS=Sel_f です：この記法は、デフ ォル ト型引数と呼ばれます。 RHS というジェネリッ 
クな型引数 （’’right hand side ”： 右辺の省略形）が 、 add メソッドの rhs 引数の型を定義しています。 
Add トレイトを実装する際に RHS の具体的な型を指定しなければ、 RHS の型は標準で Self になり、こ 
れは Add を実装している型になります。 

Point に Add を実装する際、2つの Point インスタンスを足したかったので、 RHS の規定を使用し 
ました。規定を使用するのではなく、 RHS の型をカスタマイズしたくなる Add トレイトの実装例に目 
を向けましょう。 

異なる単位で値を保持する構造体、 Millimeters と Meters (それぞれミリメートルとメートル）が 2 つ 
あります。ミリメートルの値をメートルの値に足し、 Add の実装に変換を正しくしてほしいです。 Add 
を RHS に Meters のある Milli meters に実装することができます。リスト 19-23 のように： 

ファイル名： src / lib.rs 

use std :: ops :: Add ; 


struct Mn Llimeters(u32); 
struct Meters (u32) ; 

impl Add<Meters> for Millimeters { 
type Output = Mi ill meters; 

fn add (self , other: Meters) -> Mi Hi meters { 

Millimeters (self .0 + (other.0 ^ 1000) ) 

} 

} 

リスト 19-23: Millimeters に Add トレイトを実装して、 Meters に Millimeters を足す 

Millimeters を Meters に足すため、 Self という規定を使う代わりに impl Add<Meters> を指定し 
て、 RHS 型引数の値をセットしています。 

主に2通りの方法でデフォルト型引数を使用します： 

• 既存のコードを破壊せずに型を拡張する 

• ほとんどのユーザは必要としない特定の場合でカスタマイズを可能にする 

標準ライブラリの Add トレイトは、 2 番目の目的の例です：通常、 2 つの似た型を足しますが、 Add 
トレイトはそれ以上にカスタマイズする能力を提供します。 Add トレイト定義でデフォルト型引数を 
使用することは、ほとんどの場合、追加の引数を指定しなくてもよいことを意味します。つまり、卜 
レイトを使いやすくして、ちょっとだけ実装の定型コードが必要なくなるのです。 

最初の目的は2番目に似ていますが、逆です：既存のトレイトに型引数を追加したいなら、規定を 
与えて、既存の実装コードを破壊せずにトレイトの機能を拡張できるのです。 
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19.3.3 明確化のためのフルパス記法：同じ名前のメソッドを呼ぶ 

Rust において、別のトレイトのメソッドと同じ名前のメソッドがトレイトにあったり、両方のトレ 
イトを1つの型に実装することを妨げるものは何もありません。トレイトのメソッドと同じ名前のメ 
ソッドを直接型に実装することも可能です。 

同じ名前のメソッドを呼ぶ際、コンパイラにどれを使用したいのか教える必要があるでしょう。両 
方とも fly というメソッドがある 2 つのトレイト、 Pilot と Wizard ( 訳注： パイロットと魔法使い）を 
定義したリスト 19-24 のコードを考えてください。それから両方のトレイトを既に fly というメソッ 
ドが実装されている型 Human ( 訳注： 人間）に実装します。各 fly メソッドは異なることをします。 

フアイル名： src / main.rs 

trait Pilot { 

fn fly (&self) ; 

} 

trait Wizard { 

fn fly (&self) ; 

} 

struct Human; 

impl Pilot for Human { 
fn fly(&self) { 

// キャプテンのお言葉 

println! ("This is your captain speaking. ") ; 



impl Wizard for Human { 
fn fly(&self) { 

// 上がれ！ 
println! ("Up! ") ; 



impl Human { 

fn fly(&self) { 

// ★激しく腕を振る ★ 

pri ntln! ("^.waving arms furiously* 11 ); 



リスト 19-24: 2 つの トレイトに fly があるように定義され、 Human に実装され つつ、 fly メソッド 
は Human に直接にも実装されている 

Human のインスタンスに対して fly を呼び出すと、コンパイラは型に直接実装されたメソッドを標 
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準で呼び出します。リスト 19-25 のようにですね： 

フアイル名： src / main.rs 

# trait Pilot { 

# fn fly (&self) ; 

# } 

# 

# trait Wizard { 

# fn fly (&self) ; 

# } 

# 

# struct Human; 

# 

# impl Pilot for Human { 

# fn fly(&self) { 

# println! ("This is your captain speaking. 11 ); 

# } 

# } 

# 

# impl Wizard for Human { 

# fn fly(&self) { 

# println! ("Up! ") ; 

# } 

# } 

林 

# impl Human { 

# fn fly(&self) { 

# println! ("^waving arms furiously*") ; 

# } 

# } 

# 

fn main() { 

let person = Human; 
person.fly(); 

} 


リスト 19-25： Human のインスタンスに対して fly を呼び出す 

この コー ドを実行すると、 *wavi ng arms furiously* と出力され、 コンパイ ラが Human に直接実装 
された fly メソッドを呼んでいることを示しています。 

Pilot トレイトか、 Wizard トレイトの fly メソッドを呼ぶためには、より明示的な記法を使用し 
て、どの fly メソッドを意図しているか指定する必要があります。リスト 19-26 は、この記法をデモ 
しています。 

フアイル名： src / main.rs 

# trait Pilot { 

# fn fly (&self) ; 
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# } 

# 

# trait Wizard { 

# fn fly (&self) ; 

# } 

# 

# struct Human; 

# 

# impl Pilot for Human { 

# fn fly(&self) { 

# pri ntln! ("Thi s is your captain speaking. 11 ); 

# } 

# } 

# 

# impl Wizard for Human { 

# fn fly(&self) { 

# println! ("Up! ") ; 

# } 

# } 

# 

# impl Human { 

# fn fly(&self) { 

# println! ("^waving arms furiouslv 山"）； 

# } 

# } 

# 

fn main() { 

let person = Human; 

Pilot :: fly(&person); 

Wizard :: fly(&person); 
person.fly(); 

} 

リスト 19-26: どのトレイトの fly メソッドを呼び出したいか指定する 

メソッド名の前にトレイト名を指定すると、コンパイラにどの fly の実装を呼び出したいか明確化 
できます 0 また、 Human : : fly (& person ) と書くこともでき、リスト 19-26 で使用した person . fly () 
と等価ですが、こちらの方は明確化する必要がないなら、ちょっと記述量が増えます。 

このコードを実行すると、こんな出力がされます： 

This is your captain speaking . 

Up ! 

^waving arms furiously* 

fl_y メソッドは self 引数を取るので、 1 つのトレイトを両方実装する型が 2 つあれば、コンパイラ 
には、 self の型に基づいてどのトレイトの実装を使うべきかわかるでしよう。 

しかしながら、トレイトの一部になる関連関数には self 弓 I 数がありません。同じスコープの2つ 
の型がそのトレイトを実装する場合、フルパス記法 （fully qualified syntax ) を使用しない限り、ど 
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の型を意図しているかコンパイラは推論できません。例えば、リスト 19-27 の Atvimal トレイトには、 
関連関数 baby_name 、 構造体 Dog の Animal の実装、 Dog に直接定義された関連関数 baby_name があ 
ります。 


フアイル名： src / mam.rs 

trait Animal { 

fn babv_name() -> String; 

} 

struct Dog; 
impl Dog { 

fn baby_name() -> String { 

// スポット （Wi ki pedi a によると、飼い主の事故死後もその人の帰りを待つ忠犬 
の名前の模様） 

String: : from ("Spot") 

} 

} 

imp l Animal for Dog { 

fn baby_name() -> String { 

// 子犬 

String: : f rom("puppy") 



fn main() { 

// 赤ちゃん犬は {} と呼ばれる 

println! ("A baby dog is called a {}" , Dog: : baby_name()); 

} 

リスト 19-27: 関連関数のあるトレイトとそのトレイトも実装し、同じ名前の関連関数がある型 

このコー ドは、全ての子犬をスポットと名付けたい アニマル . シェルター（訳注： 身寄りのないぺッ 
卜を保護する保健所みたいなところ）用で、 Dog に定義された baby.name 関連関数で実装されていま 
す。 Dog 型は、トレイト Animal も実装し、このトレイトは全ての動物が持つ特徴を記述します。赤ちゃ 
ん犬は子犬と呼ばれ、それが Dog の Animal トレイトの実装の Animal トレイトと紐づいた base_name 
関数で表現されています。 

main で、 Dog: : baby_name 関数を呼び出し、直接 Dog に定義された関連関数を呼び出しています 0 
このコードは以下のような出力をします： 


A baby dog is ca l Led a Spot 


この出力は、欲しかったものではありません。 Dog に実装した Animal トレイトの一^部の baby_name 
関数を呼び出したいので、コードは A baby dog is called a puppy と出力します。リスト 19-26 で 
使用したトレイト名を指定するテクニックは、ここでは役に立ちません ； mai n をリスト 19-28 のよう 
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なコードに変更したら、コンパイルエラーになるでしよう。 

フアイル名： src / main.rs 
fn main() { 

pnntln! ("A baby dog is called a {}" , Animal::baby_name()); 

} 

リスト 19-28: Animal トレイトの baby_nam e 関数を呼び出そうとするも、コンパイラにはどの実装 
を使うべきかわからない 


Animal: : baby_name はメソッドではなく関連関数であり、故に self 引数がないので、どの Animal 
:: baby_name が欲しいのか、コンパイラには推論できません。こんなコンパイルエラーが出るで 
しょう： 

error[E0283] : tvpe annotations required: cannot resolve Animal 
(エラー： 型注釈が必要です： ' Animal' を解決できません） 

-- > src/main.rs:20:43 

I 

20 | println!("A baby dog is called a {}", Animal :: babv_name()); 


=note : required by 'Animal::baby_name' 

( 注釈 ：' Animal: : baby_name' に必要です） 

Dog に対して Animal 実装を使用したいと明確化し、コンパイラに指示するには、 フルパス 記法を使 
う必要があります。 リスト 19-29 は、 フルパス 記法を使用する方法をデモしています。 

フアイル名： src / main.rs 

# trait Animal i 

# fn baby_name() -> String; 

# } 

# 

# struct Dog; 

# 

# impl Dog { 

# fn baby_name() -> String { 

# String: : f rom("Spot") 

# } 

# } 

# 

# impl Animal for Dog { 

# fn baby_name() -> String { 

# String: : f rom("puppy") 

# } 

# } 

# 

fn main() { 
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pnntln ! ("A baby dog is called a {}" , <Dog as Ammal > :: baby _ name ()); 

} 

リスト 19-29: フルパス記法を使って Dog に実装されているように、 Animal トレイトからの 
baby _ name 関数を呼び出したいと指定する 

コンパイラに山カッコ内で型注釈を提供し、これは、この関数呼び出しでは Dog 型を Animal とし 
て扱いたいと宣言することで、 Dog に実装されたように、 Animal トレイトの baby_name メソッドを呼 
び出したいと示唆しています。もうこのコードは、望み通りの出力をします： 


A baby dog is ca l Led a puppy 


一般的に、フルパス記法は、以下のように定義されています： 

<Type as Tra 1 t > :: functiorurece ] ver _ if _ method ， next _ arg , ...); 

関連関数では、 receiver がないでしょう：他の引数のリストがあるだけでしょう。関数やメソッド 
を呼び出す箇所全部で、フルパス記法を使用することもできるでしょうが、プログラムの他の情報か 
らコンパイラが推論できるこの記法のどの部分も省略することが許容されています。同じ名前を使用 
する実装が複数あり、どの実装を呼び出したいかコンパイラが特定するのに助けが必要な場合だけに 
このより冗長な記法を使用する必要があるのです。 

19.3.4 スーパートレイトを使用して別のトレイト内で、あるトレイトの機能を必要 
とする 

時として、あるトレイトに別のトレイトの機能を使用させる必要がある可能性があります。この場 
合、依存するトレイトも実装されることを信用する必要があります。信用するトレイトは、実装して 
いるトレイトのスーパートレイトです。 

例えば、アスタリスクをフレームにする値を出力する outli ne_pri nt メソッドがある Outli nePri nt 
トレイトを作りたくなったとしましょう。つまり、 Display を実装し、 （ x , y ) という結果になる Point 
構造体が与えられて、 x が1、 y が3の Poi nt インスタンスに対して outli ne_pri nt を呼び出すと、 
以下のような出力をするはずです： 


■k -k 

* (1, 3) * 
■k -k 

'k'k'k'K'k'k'k'k'k'k 


outline _ pr * int の実装では、 Display トレイトの機能を使用したいです。故に、 Display も実装す 
る型に対してだけ Outli nePri nt が動くと指定し 、 Outli nePri nt が必要とする機能を提供する必要 
があるわけです。トレイト定義で OutlinePHnt : Di splay と指定することで、そうすることができ 
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ます。このテクニックは、トレイトにトレイト境界を追加することに似ています。リスト 19-30 は、 
OutlinePrint トレイトの実装を示しています。 

フアイル名： src / main.rs 

use std :: fmt : 

trait OutlinePrint : rmt :: Display i 
fn outline _ print (& self ) { 

let output = self . to _ string (); 

let ten = output . len (); 

println !("{}" ， n * n • repeat(len +4)); 

println ! , n ". repeat(len + 2)); 

println ! ( n * {} * n , output ); 

println !("*{}*"， " repeat(len + 2)); 

println !(’’{}" ， n *" • repeat (len + 4)); 



リスト 19-30: Display からの機能を必要とする Outli nePri nt トレイトを実装する 

Outli nePri nt は Display トレイトを必要とすると指定したので、 Display を実装するどんな型に 
も自動的に実装される to_string 関数を使えます。トレイト名の後にコロンと Display トレイトを追 
加せずに to_string を使おうとしたら、現在のスコープで型 &Self に to_stri ng というメソッドは存 
在しないというエラーが出るでしょう。 

Display を実装しない型、 Point 構造体などに Outli nePri nt を実装しようとしたら、何が起きるか 
確認しましょう： 

フアイル名： src / main.rs 


# trait OutlinePnnt {} 
struct Point i 
x: i32, 

y: 1*32, 

} 

impl OutlinePrint for Point {} 

Display が必要だけれども、実装されていないというエラーが出ます： 

error[E0277] : the trait bound Point: std :: rmt :: DispLay is not satisfied 
--> src/main.rs:20:6 

I 

20 | impl OutlinePrint for Point {} 

| aaaaaaaaaaaa 'Point' cannot be formatted with the default formatter; 

try using instead if you are using a format string 


help : the trait 'std :: fmt :: Display' is not implemented for 'Point 
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これを修正するために、 Point に Display を実装し、 OutlinePrint が必要とする制限を満たしま 
す。こんな感じで： 

フ アイ ル名： src / main.rs 

# struct Point { 

# x : i 32, 

# y : 132, 

# } 

# 

use std :: fmt ; 

impl fmt :: Display for Point { 

fn fmt (& self , f : &mut fmt :: Formatter ) -> fmt :: Result { 
write ! ( f ， M ({}, {})"， self . x , self . y ) 

} 

} 

そうすれば 、 Poi nt に OutlinePri nt トレイトを実装してもコンパイルは成功し、 Point インスタン 
スに対して oufUne _ pHnt を呼び出し、アスタリスクのふちの中に表示することができます。 

19.3.5 ニュータイプパターンを使用して外部の型に外部のトレイトを実装する 

第10章の「型にトレイトを実装する」節で、トレイトか型がクレートにローカルな限り、型に卜 
レイトを実装できると述べるオーファンルールについて触れました。ニュータイプパターンを使用し 
てこの制限を回避することができ、タプル構造体に新しい型を作成することになります。（タプル構造 
体については、第5章の「異なる型を生成する名前付きフィールドのないタプル構造体を使用する」 
節で講義しました。）タプル構造体は1つのフィールドを持ち、トレイトを実装したい型の薄いラッ 
パになるでしよう。そして、ラッパの型はクレートにローカルなので、トレイトをラッパに実装でき 
ます。ニュータイプという用語は、 Haskell プログラミング言語に端を発しています。このパターン 
を使用するのに実行時のパフォーマンスを犠牲にすることはなく、ラッパ型はコンパイル時に省かれ 
ます。 

例として、 Vec < T > に Display を実装したいとしましよう。 Display トレイトも Vec < T > 型もクレー 
卜の外で定義されているので、直接それを行うことはオーファンルールにより妨げられます。 Vec < T > 
のインスタンスを保持する Wrapper 構造体を作成できます；そして、 Wrapper に Display を実装し、 
Vec < T > 値を使用できます。リスト 19-31 のように。 

フ アイ ル名： src / main.rs 

use std :: fmt : 


struct Wrapper ( Vec < btn ng >) ; 
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impl rmt :: Display tor Wrapper { 

fn fmt (& self , f : &mut fmt :: Formatter ) -> fmt :: Result { 
write ! ( f , " [{}]" , self •0. join ( n ， ") ) 

} 

} 

fn main () { 

let w = Wrapper ( vec ! [ String : : f rom (" hello ") , String : : f rom (" world M ) ]); 
println! ("w = {}" , w ); 

} 

リスト 19-31: Vec く String 〉 の周りに Wrapper を作成して Display を実装する 

Display の実装は 、 self .0 で中身の Vec < T > にアクセスしています。 Wrapper はタプル構造体で、 
Vec < T > がタプルの添え字0の要素だからです。それから、 Wrapper に対して Display 型の機能を使用 
できます。 

このテクニックを使用する欠点は、 Wrapper ■が新しい型なので、保持している値のメソッドがないこ 
とです 。 self .0 に委譲して、 Wrapper を Vec く T > と全く同様に扱えるように、 Wrapper に直接 Vec く T > 
の全てのメソッドを実装しなければならないでしょう。内部の型が持つ全てのメソッドを新しい型に 
持たせたいなら、 Deref トレイト（第15章の 「 Deref トレイトでスマートポインタを普通の参照のよ 
うに扱う」節で議論しました）を Wrapper に実装して、内部の型を返すことは解決策の1つでしょう。 
内部の型のメソッド全部を Wrapper 型に持たせたくない（例えば、 Wrapper 型の機能を制限するなど) 
なら、本当に欲しいメソッドだけを手動で実装しなければならないでしょう。 

もう、トレイトに関してニュータイプパターンが使用される方法を知りました；トレイトが関連し 
なくても、有用なパターンでもあります。焦点を変更して、 Rust の型システムと相互作用する一部の 
高度な方法を見ましょう。 

19.4 高度な型 

Rust の型システムには、この本で触れたけれども、まだ議論していない機能があります。ニュータ 
イプが何故型として有用なのかを調査するため、一般化してニュータイプを議論することから始めま 
す。そして、型エイリアスに移ります。ニュータイプに類似しているけれども、多少異なる意味を持 
つ機能です。また、！型と動的サイズ付け型も議論します。 

注釈：次の節は、前節「外部の型に外部のトレイトを実装するニュータイプパターン」を読了 
済みであることを前提にしています。 
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19.4.1 型安全性と抽象化を求めてニュータイプパターンを使用する 

ここまでに議論した以上の作業についてもニュータイプパターンは有用で、静的に絶対に値を混同 
しないことを強制したり、値の単位を示すことを含みます。ニュータイプを使用して単位を示す例を 
リスト 19-23 で見かけました ： Mi Hi meters と Meters 構造体は、 u 32 値をニュータイプにラップして 
いたことを思い出してください。型 Millimeters を引数にする関数を書いたら、誤ってその関数を型 
Meters や普通の u 32 で呼び出そうとするプログラムはコンパイルできないでしょう。 

型の実装の詳細を抽象化する際にニュータイプパターンを使用するでしょう：例えば、新しい型を 
直接使用して、利用可能な機能を制限したら、非公開の内部の型の API とは異なる公開 API を新し 
い型は露出できます。 

ニュータイプはまた、内部の実装を隠匿（いんとく）することもできます。例を挙げれば、 People 型 
を提供して、人の ID と名前を紐づけて格納する HashMap < i 32, String 〉 をラップすることができる 
でしょう。 People を使用するコードは、名前の文字列を People コレクションに追加するメソッドな 
ど、提供している公開 API とだけ相互作用するでしょう；そのコードは、内部で彳32 ID を名前に代入 
していることを知る必要はないでしょう。ニュータイプパターンは、カプセル化を実現して実装の詳 
細を隠匿する軽い方法であり、実装の詳細を隠匿することは、第17章の「カプセル化は実装詳細を 
隠蔽する」節で議論しましたね。 

19.4.2 型エイリアスで型同義語を生成する 

ニュータイプパターンに付随して、 Rust では、既存の型に別の名前を与える型 エイリアス （type 
alias : 型別名）を宣言する能力が提供されています。このために、 type キーワードを使用します。例 
えば、以下のように i 32 に対して Kilometers というエイリアスを作れます。 

type Kilometers = i 32 ; 

これで、別名の Kilometers は i 32 と同義語になりました；リスト 19-23 で生成した Millimeters 
と Meters とは異なり、 Kilometers は個別の新しい型ではありません。型 Kilometers の値は、型 i 32 
の値と同等に扱われます。 

type Kilometers = i 32 ; 

let x : i 32 = 5; 

let y : Kilometers = 5; 

println! ("x + y = {}" , x + y ); 

Kilometers と i 32 が同じ型なので、両方の型の値を足し合わせたり、 Kilometers の値を i 32 引数 
を取る関数に渡せたりします。ですが、この方策を使用すると、先ほど議論したニュータイプパター 
ンで得られる型チェックの利便性は得られません。 
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型同義語の主なユースケースは、繰り返しを減らすことです。例えば、こんな感じの長い型がある 
かもしれません： 


Box く Fn() + Send + ’static 〉 

この長ったらしい型を関数シグニチャや型注釈としてコードのあちこちで記述するのは、面倒で間 
違いも起きやすいです。リスト 19-32 のそのようなコードで溢れかえったプロジェクトがあることを 
想像してください。 


let f : Box く Fn () + Send + ' static > = Box :: new (|| println ! (" hi ") ); 

fn takes _ long _ type ( f : Box < Fn () + Send + ' stati c >) { 

// -- snip -- 

} 

fn returns _ long _ type () -> Box < Fn () + Send + ' stati c > { 

// -- snip -- 
# Box :: new (|| ()) 

} 

リスト 19-32: 長い型を多くの場所で使用する 

型エイリアスは、繰り返しを減らすことでこのコードをより管理しやすくしてくれます。リスト 
19-33 で、冗長な型に Thunk (注釈： 塊）を導入し、その型の使用全部をより短い別名の Thunk で置き 
換えることができます。 


type I'nunk = Box<Fn () + Send + ' stati c> ; 

let f: Thunk = Box: : new(|| println! ("hi ") ); 

fn takes_long_type(f: Thunk) { 

// --snip-- 

} 


fn returns_long_type() -> Thunk { 

// --snip-- 
# Box :: new(| 丨 ()) 

} 

リスト 19-33： 型エイリアスの Thunk を導入して繰り返しを減らす 

このコードの方が遥かに読み書きしやすいです！型エイリアスに意味のある名前を選択すると、意 
図を伝えるのにも役に立つことがあります （ thunk は後ほど評価されるコードのための単語なので、 
格納されるクロージャーには適切な名前です)。 

型エイリアスは、繰り返しを減らすために Results, E> 型ともよく使用されます。標準ライブ 
ラリの std :: io モジュールを考えてください。 I / O 処理はしばしば、 Results, E> を返して処理が 
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うまく動かなかった時を扱います。このライブラリには、全ての可能性のある I / O エラーを表す 
std : : io : : Error ■構造体があります。 std : : io の関数の多くは、 Wri te トレイトの以下の関数のように 
巳が std: : io: : Error の Result<T, E> を返すでしよう： 

use std : :io: : Error; 
use std :: fmt ; 

pub trait Write { 

fn write (&mut self, buf : & [u8]) -> Result<usize, Error 〉； 
fn flush (&mut self) -> Result< (), Error 〉； 

fn write_all(&mut self, buf: &[u8]) -> Result< (), Error 〉； 

fn write_fmt (&mut self, fmt: fmt: : Arguments) -> Result< (), Error 〉； 

} 

Result く ...， Errors が何度も繰り返されてます。そんな状態なので、 std : : io にはこんな類のエイ 
リアス宣言があります： 


type Resu Lt<T> = Result く T ， std :: io :: ヒ rror> ; 

この宣言は std :: io モジ ユール 内にあるので、フ ルパスエイ リアスの std : : io : : Result く T> を使用 
できます。つまり、 E が std : : io :: Error で埋められた Result く T ， E> です。その結果、 Write トレイ 
卜の関数シグニチヤは、以下のような見た目になります： 


pub trait Write { 

fn write(&mut self , buf : &[ u 8]) -> Result く usize > ; 
fn flush (&mut self ) -> Result < ()>; 

fn write 一 all(&mut self , buf : &[ u 8]) -> Result < ()>; 
fn write _ fmt (&mut self , fmt : Arguments ) -> Result < ()>; 

} 

型ェイリアスは、2通りの方法で役に立っています：コードを書きやすくすることと std ：： io を通 
して首尾一貫したインターフヱイスを与えてくれることです。別名なので、ただの Result < T ， E > で 
あり、要するに Result < T , E > に対して動くメソッドはなんでも使えるし、？演算子のような特殊な記 
法も使えます。 


19.4 .3 never 型は絶対に返らない 

Rust には、型理論用語で値がないため、空型として知られる！という特別な型があります。私たち 
は、関数が絶対に返らない時に戻り値の型の場所に立つので、 never type (訳注：日本語にはできな 
いので、 never 型と呼ぶしかないか）と呼ぶのが好きです。こちらが例です： 

fn bar () -> ! { 

// -- snip -- 
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} 

このコードは、「関数 bar は never を返す」と解読します。 never を返す関数は、 発散する関数 
(diverging function ) と呼ばれます。型！の値は生成できないので、 bar が返ることは絶対にあり得 
ません。 

ですが、値を絶対に生成できない型をどう使用するのでしょうか？リスト 2-5 のコードを思い出 
してください；リスト 19-34 に一部を再現しました。 

# let guess = "3" ; 

# loop { 

let guess : u 32 = match guess . tnm () .parseu { 

Ok ( num ) => num , 

Err し） => continue , 

}； 

# break ; 

# } 

リスト 19-34: continue になるアームがある match 

この時点では、このコードの詳細の一部を飛ばしました。第6章の 「 match フロー制御演算子」節 
で、 match アームは全て同じ型を返さなければならないと議論しました。従って、例えば以下のコー 
ドは動きません： 

let guess = match guess . trim (). parse () { 

Ok し） => 5， 

Err し）：〉 " hello ", 

} 

このコードの guess は整数かつ文字列にならなければならないでしょうが、 Rust では、 guess は 
1つの型にしかならないことを要求されます。では、 continue は何を返すのでしょうか？どうやっ 
てリスト 19-34 で1つのアームからは u 32 を返し、別のアームでは、 continue で終わっていたので 
しょうか？ 

もうお気付きかもしれませんが、 continue は！値です。つまり、コンパイラが guess の型を計算す 
る時、両方の match アームを見て、前者は U 32 の値、後者は！値となります。！は絶対に値を持ち得 
ないので、コンパイラは、 guess の型は u 32 と決定するのです。 

この振る舞いを解説する公式の方法は、型！の式は、他のどんな型にも型強制され得るということ 
です。この match アームを continue で終えることができます。何故なら、 continue は値を返さない 
からです；その代わりに制御をループの冒頭に戻すので、 Err の場合、 guess には絶対に値を代入しな 
いのです。 

never 型は、 panic ! マクロとも有用です。 0 ption < T > 値に対して呼び出して、値かパニックを生成 
した unwrap 関数を覚えていますか？こちらがその定義です： 
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impl く T> Option く T> { 

pub fn unwrap(self) - > T { 
match self { 

Some(val) => val, 

None => panic! ("called 'Option::unwrap()' on a 'None' value") , 



} 

このコードにおいて、リスト 19-34 の match と同じことが起きています：コンパイラは、 vat の型 
は T で、 panic! の型は！なので、 match 式全体の結果は T と確認します。 panic! は値を生成しないの 
で、このコードは動きます。つまり、プログラムを終了するのです。 None の場合、 unwrap から値は返 
さないので、このコードは合法なのです。 

型が！の最後の式は、10 op です： 

//永遠に 

onnt ! ("forever ") ; 
loop { 

// さらに永遠に 

print! ("and ever ") ; 

} 

ここで、ループは終わりませんので、！が式の値です。ところが、 break を含んでいたら、これは真 
実にはならないでしょう。 break に到達した際にループが終了してしまうからです。 

19.4.4 動的サイズ付け型と Sized トレイト 

コンパイラが特定の型の値1 つに どれくらいの スペースの メモリを確保するのかなどの特定の詳細 
を知る必要があるために、型システムには混乱することもある秘密の場所があります：動的サイズ付 
け型の概念です。時として DST やサイズなし型とも称され、これらの型により、実行時にしかサイ 
ズを知ることのできない値を使用するコードを書かせてくれます。 

str と呼ばれる動的サイズ付け型の詳細を深掘りしましょう。本を通して使用してきましたね。そ 
うです。 & str ではなく、 str は単独で DST なのです。実行時までは文字列の長さを知ることができ 
ず、これは、型 str の変数を生成したり、型 str を引数に取ることはできないことを意味します。動 
かない以下のコードを考えてください： 

//こんにちは 

let si: str = "Hello there! 11 ; 

// 調子はどう？ 

let s2 : str = "How's it going?"; 


コンパイラは、特定の型のどんな値に対しても確保するメモリ量を知る必要があり、ある型の値は 
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全て同じ量のメモリを使用しなければなりません。 Rust でこのコードを書くことが許容されたら、こ 
れら 2 つの str 値は、同じ量のスペースを消費する必要があったでしょう。ですが、長さが異なりま 
す： S 1 は、12バイトのストレージが必要で、 S 2 は15バイトです。このため、動的サイズ付け型を保 
持する変数を生成することはできないのです。 

では、どうすればいいのでしょうか？この場合、もう答えはご存知です： si と S2 の型を str では 
なく、 &str にすればいいのです。第4章の「文字列スライス」節でスライスデータ構造は、開始地点 
とスライスの長さを格納していると述べたことを思い出してください。 

従って、 &T は、 T がどこにあるかのメモリアドレスを格納する単独の値だけれども、 &str は2つ 
の値なのです： str のアドレスとその長さです。そのため、 コンパイル 時に &str のサイズを知ること 
ができます： usize の長さの 2 倍です。要するに、参照している文字列の長さによらず、常に &str の 
サイズがわかります。通常、このようにして Rust では動的サイズ付け型が使用されます：動的情報 
のサイズを格納する追加のちょっとしたメタデータがあるのです。動的サイズ付け型の黄金規則は、 
常に動的サイズ付け型の値をなんらかの種類のポインタの背後に配置しなければならないということ 
です。 

str を全ての種類のポインタと組み合わせられます：例を挙げれば、 Box<str> や Rc<str> などで 
す。実際、これまでに見かけましたが、異なる動的サイズ付け型でした：トレイトです。全てのトレイ 
卜は、トレイト名を使用して参照できる動的サイズ付け型です。第17章の「トレイトオブジェクト 
で異なる型の値を許容する」節で、トレイトをトレイトオブジェクトとして使用するには、 &Trait や 
Box<Trait> ( RC も動くでしょう）など、ポインタの背後に配置しなければならないことに触れました。 

DST を扱うために、 Rust には Sized トレイトと呼ばれる特定のトレイトがあり、型のサイズがコ 
ンパイル時にわかるかどうかを決定します。このトレイトは、コンパイル時にサイズの判明する全て 
のものに自動的に実装されます。加えて、コンパイラは暗黙的に全てのジヱネリックな関数に Sized 
の境界を追加します。つまり、こんな感じのジェネリック関数定義は： 

tn genen c<T> (t : T) { 

II snip__ 

} 

実際にはこう書いたかのように扱われます： 

fn genenc<T : Sized>(t: T) { 

// --snip-- 

} 

規定では、ジヱネリック関数はコンパイル時に判明するサイズがある型に対してのみ動きます。で 
すが、以下の特別な記法を用いてこの制限を緩めることができます： 


fn generic く T: ?Sized>(t: &T) { 
// --snip-- 

} 
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? Sized のトレイト境界は、 Sized のトレイト境界の逆になります：これを 「 T は Sized かもしれな 
いし、違うかもしれない」と解読するでしょう。この記法は、 Sized にのみ利用可能で、他のトレイ 
卜にはありません。 

また、 t 引数の型を T から & T に切り替えたことにも注目してください。型は Sized でない可能性が 
あるので、なんらかのポインタの背後に使用する必要があるのです。今回は、参照を選択しました。 
次は、関数とクロージャについて語ります！ 

19.5 高度な関数とクロージャ 

最後に関数とクロージャに関連する高度な機能の一部を探究し、これには関数ボインタとクロー 
ジャの返却が含まれます。 

19.5.1 関数ポインタ 

クロージャを関数に渡す方法について語りました；普通の関数を関数に渡すこともできるのです！ 
新しいクロージャを定義するのではなく、既に定義した関数を渡したい時にこのテクニックは有用で 
す。これを関数ポインタで行うと、関数を引数として他の関数に渡して使用できます。関数は、型 fn 
(小文字の f です）に型強制されます。 Fn クロージャトレイトと混同すべきではありません。 fn 型は、 
関数ポインタと呼ばれます。引数が関数ポインタであると指定する記法は、クロージャのものと似て 
います。リスト 19-35 のように。 

フアイル名： src / main.rs 

fn add _ one ( x : i 32) -> i 32 { 
x + 1 

} 

fn do _ twice ( f : fn ( i 32) -> i32 , arg : 1.32) -> i 32 { 
f ( arg ) + f ( arg ) 

} 

fn main () { 

let answer = do _ twice ( add _ one , 5); 

// 答えは {} 

println! ("The answer is : {}" , answer ); 

} 

リスト 19-35: fn 型を使用して引数として関数ボインタを受け入れる 

このコ^ードは 、 The answer is : 12と出力します。 do _ twice の引数 f は、型 i 32 の1つの引数を 
取り、132を返す fn と指定しています。それから、 do _ twice の本体で f を呼び出すことができます。 
main では、関数名の add _ one を最初の引数として do _ twice に渡せます。 
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クロージャと異なり、 fn はトレイトではなく型なので、トレイト境界として Fn トレイトの1つで 
ジェネリックな型引数を宣言するのではなく、直接 fn を引数の型として指定します。 

関数ポインタは、クロージャトレイト3つ全て （ Fn 、 FnMut 、 FnOnce ) を実装するので、常に関数 
ポインタを引数として、クロージャを期待する関数に渡すことができます。関数が関数とクロージャ 
どちらも受け入れられるように、ジェネリックな型とクロージャトレイトの1つを使用して関数を書 
くのが最善です。 

クロージャではなく fn だけを受け入れたくなる箇所の一例は、クロージャのない外部コードとの 
インターフヱイスです： C 関数は引数として関数を受け入れられますが、 C にはクロージャがありま 
せん。 

インラインでクロージャが定義されるか、名前付きの関数を使用できるであろう箇所の例として、 
map の使用に目を向けましょう。 map 関数を使用して数字のベクタを文字列のベクタに変換するには、 
このようにクロージャを使用できるでしょう： 

let It st _ of_numbers = vec !|_ 丄，2， 3」； 
let list _ of _ strings : Vec < Str * ing > = list _ of_numbers 
• iter () 

. map (| i | i . to _ string ()) 

. collect (); 

あるいは、このようにクロージャの代わりに map に引数として関数を名指しできるでしょう： 

let It st _ of_numbers = vec ! [1, 2, 3」； 
let list _ of _ strings : Vec < String > = list _ of_numbers 
• iter () 

. map ( ToStri ng : : to _ string ) 

. collect (); 

先ほど「高度なトレイト」節で語ったフルパス記法を使わなければならないことに注意してくださ 
い。というのも、 to _ string という利用可能な関数は複数あるからです。ここでは、 ToString トレイ 
卜で定義された t 0 _ string 関数を使用していて、このトレイトは標準ライブラリが、 Display を実装 
するあらゆる型に実装しています。 

このスタイルを好む方もいますし、クロージャを使うのを好む方もいます。どちらも結果的に同じ 
コードにコンパイルされるので、どちらでも、自分にとって明確な方を使用してください。 

19.5.2 クロージャを返却する 

クロージャはトレイトによって表現されます。つまり、クロージャを直接は返却できないのです。 
トレイトを返却したい可能性のあるほとんどの場合、代わりにトレイトを実装する具体的な型を関数 
の戻り値として使用できます。ですが、クロージャではそれはできません。返却可能な具体的な型が 
ないからです；例えば、関数ボインタの fn を戻り値の型として使うことは許容されていません。 

以下の コードは、 クロージャを直接返そうと してい ますが、 コンパイルで きません： 
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fn returns _ closure () -> Fn ( i 32) -> i 32 { 

| x | x + 1 

} 

コンパイルエラーは以下の通りです： 

error [ E 0277] : the trait bound std :: ops :: Fn い 32)-> i 32 + ' static : 
std : : marker: : Sizea is not satisfied 
—— > 

I 

1 | fn returns _ closure () -> Fn ( i 32) -> i 32 { 

| a 八八八八八八八八八八八八 a ' std :: ops :: Fn ( i 32) -> i 32 + ' static ' 

does not have a constant size known at compile-time 

I 

=he Lp : the trait ' std : : marker: : Si zed ' is not implemented for 
' std :: ops :: Fn ( i 32) -> i 32 + ' static ' 

= note : the return type of a function must have a statically known size 

エラーは、再度 Sized トレイトを参照しています！コンパイラには、クロージャを格納するのに 
必要なスペースがどれくらいかわからないのです。この問題の解決策は先ほど見かけました。トレイ 
トオブジェクトを使えます： 


fn returns _ closure () -> Box く Fn ( i 32) -> i 32> { 

Box : : new ( 丨 x 丨 x + 1) 

} 

このコードは、 問題なく コンパイルで きます。トレイトオブジェクト について 詳しくは、第17章 
の「トレイトオブジェクトで異なる型の値を許容する」節を参照してください。 

19.6 まとめ 

ふう！もう道具箱に頻繁には使用しない Rust の機能の一部がありますが、非常に限定された状況 
で利用可能だと知るでしょう。エラーメッセージや他の方のコードで遭遇した際に、これらの概念や 
記法を認識できるように、複雑な話題をいくつか紹介しました。この章は、解決策へ導く参考文献と 
してご活用ください。 

次は、本を通して議論してきた全てを実践に配備し、もう1つプロジェクトを熟（こな）します！ 
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最後のプロジェクト：マルチスレッドの 
Web サーバを構築する 


長い旅でしたが、本の末端に到達しました。この章では、共にもう一つプロジヱタトを構築して最 
後の方の章で講義した概念の一部をデモしつつ、前のレッスンを思い出してもらいます。 

最後のプロジェクトでは、 hello と話す Web サーバを作り、 Web ブラウザでは、図 20-1 のよう 
な見た目になります。 _ 

Hello ! X + 

+ ① 127.0.0.1:8080 


Hello! 


Hi Irom Rust 


図 20-1: 最後の共有されたプロジェクト 
こちらが Web サーバを構築するプランです： 

1. TCP と HTTP について 少し学ぶ。 

2. ソケットで TCP 接続をリッスンする。 

3. 少量の HTTP リクエストを構文解析する。 

4. 適切な HTTP レスポンスを生成する。 

5. スレッドプールでサーバのスループッ トを強化す る。 
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ですが、取り掛かる前に、ある詳細に触れるべきです：使用する方法は、 Rust で' Web サーバを構 
築する最善の方法ではないのです。これから構築するよりもより完全な' Web サーバとスレッドプー 
ルの実装を提供する製品利用可能な多くのクレートが、 https://crates.io/ で利用可能なのです。 

しかしながら、この章での意図は、学習の手助けであり、簡単なルートを選ぶことではありません。 
Rust はシステムプログラミング言語なので、取りかかる抽象度を選ぶことができ、他の言語で可能 
だったり実践的だったりするよりも低レベルまで行くことができます。一般的な考えと将来使う可能 
性のあるクレートの背後にある技術を学べるように、手動で基本的な HTTP サーバとスレッドプール 
を書きます。 

20.1 シングルスレツドの Web サーバを構築する 

シングルスレッドの Web サーバを動かすところから始めます。始める前に、 Web サーバ構築に関 
係するプロトコルをさっと一覧しましょう。これらのプロトコルの詳細は、この本の範疇を超えてい 
ますが、さっと眺めることで必要な情報が得られるでしょう。 

主に2つのプロトコルが Web サーバに関係し、 Hypertext Transfer Protocol (HTTP) (注釈： 
ハイパーテキスト転送プロトコル）と、 Transmission Control Protocol (TCP) (注釈：伝送制御 
プロトコル）です。両者のプロトコルは、リクエスト■レスポンスプロトコルであり、つまり、クライ 
アントがリクエスト（要求）を初期化し、サーバはリクエストをリッスンし、クライアントにレスボン 
ス（応答）を提供するということです。それらのリクエストとレスポンスの中身は、プロトコルで規定 
されています。 

TCP は、情報がとあるサーバから別のサーバへどう到達するかの詳細を記述するものの、その情報 
がなんなのかは指定しない、より低レベルのプロトコルです。 HTTP はリクエストとレスポンスの中 
身を定義することで TCP の上に成り立っています。技術的には HTTP を他のプロトコルとともに使 
用することができますが、過半数の場合、 HTTP は TCP の上にデータを送信します。 TCP と HTTP 
のリクエストとレスポンスの生のバイトを取り扱います。 

20.1.1 TCP 接続をリッスンする 

Web サーバは TCP 接続をリッスンするので、そこが最初に取り掛かる部分になります。標準ライ 
ブラリは、 std : : net というこれを行うモジュールを用意しています。通常通り、新しいプロジェクト 
を作りましょう： 


5 cargo new he llo --bin 

Created binary ( application ) ' hello ' project 
$ cd hello 

さて、リスト 20-1 のコードを src/main.rs に入力して始めてください。このコードは、やってく 
る TCP ストリームを求めて 127.0.0.1:7878 というアドレスをリッスンします。入カストリームを得 
ると、 Connection established ! と出力します。 
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フアイル名： src / mam.rs 
use std: : net: :TcpListener; 
rn main() { 

let listener = Tcp Listener: : bind ("127. 0.0.1:7878") .unwrap(); 

for stream in It stener. i ncoming() { 
let stream = stream.unwrapO ; 

// 接続が確立しました 

println! ("Connection established! ") ; 



リスト 20-1: 入カストリームをリッスンし、ストリームを受け付けた時にメッセージを出力する 

TcpListener により、アドレス 127 • 0 • 0 . 1:7878 で TCP 接続をリッスンできます。アドレス内で、 
コロンの前の区域は、自分のコンピュータを表す IP アドレスで（これはどんなコンピュータでも同じ 
で、特に著者のコンピュータを表すわけではありません)、 7878 はポートです。このポートを選択し 
た理由は2つあります： HTTP は通常このポートで受け付けられることと、7878は電話で “ rust ” と 
入力されるからです。 

この筋書きでの bind 関数は、新しい TcpLi stener インスタンスを返すという点で new 関数のよう 
な働きをします。この関数が bind と呼ばれている理由は、ネットワークにおいて、リッスンすべき 
ポートに接続することは、「ポートに束縛する」 （ bindingtoaport ) こととして知られているから 
です。 

bind 関数は Resul_t<T, E> を返し、束縛が失敗することもあることを示しています。例えば、ポー 
卜80に接続するには管理者権限が必要なので（管理者以外はポート1024以上しかリッスンできま 
せん）管理者にならずにポート80に接続を試みたら、束縛はうまくいかないでしょう。また、別の例 
として自分のプログラムを2つ同時に立ち上げて2つのプログラムが同じポートをリッスンしたら、 
束縛は機能しないでしょう。学習目的のためだけに基本的なサーバを記述しているので、この種のエ 
ラーを扱う心配はしません；その代わり、 unwrap を使用してエラーが発生したら、プログラムを停止 
します。 

TcpListener の i ncomi ng メソッドは、一連のストリームを与えるイテレータを返します（具体的に 
は、型 TcpStream のストリーム)。単独のストリームがクライアント.サーバ間の開かれた接続を表し 
ます。接続 （ connection ) は、クライアントがサーバに接続し、サーバがレスポンスを生成し、サー 
バが接続を閉じるというリクエストとレスポンス全体の過程の名前です。そのため、 TcpStream は自 
身を読み取って、クライアントが送信したことを確認し、それからレスポンスをストリームに記述さ 
せてくれます。総括すると、この for ループは各接続を順番に処理し、我々が扱えるように一連のス 
トリームを生成します。 

とりあえず、ストリームの扱いは、 unwrap を呼び出してストリームにエラーがあった場合にプログ 
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ラムを停止することから構成されています；エラーがなければ、プログラムはメッセージを出力しま 
す。次のリストで成功した時にさらに多くの機能を追加します。クライアントがサーバに接続する際 
に incoming メソッドからエラーを受け取る可能性がある理由は、実際には接続を走査していないか 
らです。代わりに接続の試行を走査しています。接続は多くの理由で失敗する可能性があり、そのう 
ちの多くは、 OS 特有です。例を挙げれば、多くの OS には、サポートできる同時に開いた接続数に 
上限があります；開かれた接続の一部が閉じられるまでその数字を超えた接続の試行はエラーになり 
ます。 

このコードを試しに実行してみましょう！端末で cargo run を呼び出し、それから Web ブラウザ 
で 127.0 .0.1:7878 をロードしてください。ブラウザは、「接続がリセットされました」などの エラー 
メッセージを表示するはずです。サーバが現状、何もデータを返してこないからです。ですが、端末 
に目を向ければ、ブラウザがサーバに接続した際にいくつかメッセージが出力されるのを目の当たり 
にするはずです。 

Running target / debug/heVLo 
Connection established ! 

Connection established ! 

Connection established ! 


時々、 1 回のブラウザリクエストで複数のメッセージが出力されるのを目の当たりにするでしょう； 
その理由は、ブラウザがページだけでなく、ブラウザのタブに出現する favicon.ico アイコンなどの 
他のリソースにもリクエストを行なっているということかもしれません。 

サーバが何もデータを送り返してこないので、ブラウザがサーバに何度も接続を試みているという 
ことである可能性もあるでしょう。 stream がスコープを抜け、ループの最後でドロップされると、接 
続は drop 実装の一部として閉じられます。ブラウザは、再試行することで閉じられた接続を扱うこ 
とがあります。問題が一時的なものである可能性があるからです。重要な要素は、 TCP 接続へのハン 
ドルを得ることに成功したということです！ 

特定のバージョンのコードを走らせ終わった時に ctrl-c を押して、プログラムを止めることを忘れ 
ないでください。そして、一連のコード変更を行った後に cargo run を再起動し、最新のコードを実 
行していることを確かめてください。 

20.1 .2 リクエストを読み取る 

ブラウザからリクエストを読み取る機能を実装しましょう！まず接続を得、それから接続に対し 
て何らかの行動を行う責任を分離するために、接続を処理する新しい関数を開始します。この新しい 
handle _ connection 関数において、 TCP ストリームからデータを読み取り、ブラウザからデータが送 
られていることを確認できるように端末に出力します。コードをリスト 20-2 のように変更してくだ 
さい。 


ファイル名： src / main.rs 
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use std : :]〇: :preLude: 
use std :: net : : TcpStream ; 
use std : : net : : TcpListener ; 

fn main () { 

let listener = TcpListener : : bind ("127.0.0.1 :7878") .unwrapO ; 

for stream in listener . incoming () { 
let stream = stream.unwrapO ; 


} 


handle _ connection ( stream ); 

} 


fn handle _ connection (mut stream : TcpStream ) { 
let mut buffer = [0; 512]; 

stream , read (&mut buffer ) .unwrapO ; 

println ! (" Request : {}" , String : : from _ utf 8_ lossy (& buffer [..])); 

} 

リスト 20-2: TcpStream から読み取り、データを出力する 

std : : io : : prelude をスコープに導入して、ストリームから読み書きさせてくれる特定のトレイト 
にアクセスできるようにしています。 main 関数内の for ループで、接続を確立したというメッセージ 
を出力する代わりに、今では、新しい handle_connection 関数を呼び出し、 stream を渡しています。 

handle_connection 関数において、 stream 引数を可変にしました。理由は、 TcpStream インスタン 
スが内部で返すデータを追いかけているからです。要求した以上のデータを読み取り、次回データを 
要求した時のためにそのデータを保存する可能性があります。故に、内部の状態が変化する可能性が 
あるので、 mut にする必要があるのです；普通、「読み取り」に可変化は必要ないと考えてしまいます 
が、この場合、 mut キーワードが必要です。 

次に、実際にストリームから読み取る必要があります。これを2つの手順で行います：まず、スタッ 
クに読み取ったデータを保持する buffer を宣言します。バッファーのサイズは512バイトにしまし 
た。これは、基本的なリクエストには十分な大きさでこの章の目的には必要十分です。任意のサイズ 
のリクエストを扱いたければ、バッファーの管理はもっと複雑にする必要があります；今は、単純に 
保っておきます。このバッファーを stream , read に渡し、これが TcpStream からバイトを読み取って 
バッファーに置きます。 

2 番目にバッファーのバイトを文字列に変換し、その文字列を出力します。 String :: 
from _ utf 8 _lossy 関数は、& [ u 8] を取り、 String を生成します。名前の ‘ lossy ” の箇所は、無効な 
UTF -8 シーケンスを目の当たりにした際のこの関数の振る舞いを示唆しています：無効なシーケンス 
を？、 U + FFFD REPLACEMENT CHARACTER で置き換えます。置き換え文字をリクエストデータによって 
埋められたバッファーの文字の箇所に目撃する可能性があります。 
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このコードを試しましょう！プログラムを開始して Web ブラウザで再度リクエストを送ってくだ 
さい。ブラウザではそれでも、エラーページが得られるでしょうが、端末のプログラムの出力はこん 
な感じになっていることに注目してください： 

^ cargo run 

Compiung he ilo v0.1.0 (ti Le:///pro]ects/hello) 

Finished dev [unoptimized + debuginfo ] target ( s ) in 0.42 secs 
Running ' target / debug / hello ' 

Request : GET / HTTP /1.1 
Host ： 127.0.0.1:7878 

User - Agent : Mozilla /5.0 (Windows NT 10.0; W 0 W 64; rv :52.0) Gecko / 20100101 
Firefox /52.0 

Accept : text / html , application / xhtml + xml , application / xml ; q =0.9,; q =0.8 

Accept - Language : en - US , en ; q =0.5 

Accept - Encoding : gzip , deflate 

Connection : keep-alive 

Upgrade - Insecure - Requests : 1 

7 ??????????????????????????????????? 


ブラウザによって、少し異なる出力になる可能性があります。今やリクエストデータを出力してい 
るので、 Request : GET の後のパスを見ることで1回のブラウザリクエストから複数の接続が得られ 
る理由が確認できます。繰り返される接続が全て/を要求しているなら、ブラウザは、我々のプログ 
ラムからレスポンスが得られないので、繰り返し/をフェッチしようとしていることがわかります。 
このリクエストデータを嚙み砕いて、ブラウザが我々のプログラムに何を要求しているかを理解し 

ましょ5。 

20.1 .3 HTTP リクエストを詳しく見る 

HTTP はテキストベースのプロトコルで、 1 つの要求はこのようなフォーマツトに則っています： 


Method Request-URI HTTP-Version CRLF 

headers CRLF 

message-body 


1 行目は、クライアントが要求しているものがなんなのかについての情報を保持するリクエスト行 
です。リクエスト行の最初の部分は使用されている GET や POST などのメソッドを示し、これは、ど 
のようにクライアントがこの要求を行なっているかを記述します。クライアントは GET リクエストを 
使用しました。 

リクエスト行の次の部分は/で、これはクライアントが要求している Uniform Resource Iden- 
tifier (URI) ( 注釈： 統一資源識別子）を示します： URI はほぼ、ですが完全ではなく、 Uniform 
Resource Locator (URL) ( 注釈： 統一資源位置指定子）と同じです。 URI と URL の違いは、この章 
の目的には重要ではありませんが、 HTTP の規格は URI という用語を使用しているので、ここでは脳 
内で URI を URL と読み替えられます。 

最後の部分は、クライアントが使用している HTTP のバージョンで、それからリクエスト行は 
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CRLF で終了します。 （ CRLF は carriage return と line feed (無理に日本語でいえば、キャリッ 
ジ（紙を固定するシリンダー）が戻ることと行を（コンピュータに）与えること）を表していて、これは 
タイプライター時代からの用語です！ ) CRLF は \ r \ n とも表記され、 \ r がキャリッジ•リターンで \n 
がライン•フィードです。 CRLF により、リクエスト行がリクエストデータの残りと区別されていま 
す。 CRLF を出力すると、 \ r \ n ではなく、新しい行が開始されることに注意してください。 

ここまでプログラムを実行して受け取ったリクエスト行のデータをみると、 GET がメソッド、/が要 
求 URL HTTP /1.1 がバージョンであることが確認できます。 

リクエスト行の後に、 Host : 以下から始まる残りの行は、ヘッダです。 GET リクエストには、本体 
がありません。 

試しに他のブラウザからリクエストを送ったり、 127.0 .0.1:7878/test などの異なるアドレスを要 
求してみて、どうリクエストデータが変わるか確認してください。 

さて、ブラウザが要求しているものがわかったので、何かデータを返しましょう！ 

20.1 .4 レスポンスを記述する 

さて、クライアントのリクエストに対する返答としてデータの送信を実装します。レスポンスは、 
以下のようなフォーマットです： 


HTTP-Version Status-Code Reason-Phrase CRLF 

headers CRLF 

message-body 


最初の行は、レスポンスで使用される HTTP バージョン、リクエストの結果を要約する数値ステー 
タス.コード、そしてステータス.コードのテキスト記述を提供する理由句を含むステータス行です。 
CRLF シーケンスの後には、任意のヘッダ、別の CRLF シーケンス、そしてレスポンスの本体が続き 
ます。 

こちらが HTTP バージョン 1.1 を使用し、ステータスコードが200で、 0 K フレーズ、ヘッダと本 
体なしの例のレスポンスです： 


HTTP /1.1 200 0 K \ r \ n \ r\n 


ステータスコード200は、一般的な成功のレスポンスです。テキストは、矮小（わいしょう）な成 
功の HTTP レスポンスです。これを成功したリクエストへの返答としてストリームに書き込みましょ 
う！ handle_connection 関数から、リクエストデータを出力していた pri ntln !を除去し、リスト 
20-3 のコードと置き換えてください。 

フアイル名： src / main.rs 


# use std : : io : : prelude : :〇,; 

# use std : : net : : TcpStream ; 

fn handle _ connection (mut stream : TcpStream ) { 
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let mut buffer = [0; 512] ; 

stream . read (&mut buffer ;. unwrap (); 

let response = " HTTP / l .1200 0 K \ r \ n \ r \ n " ; 

stream . write ( response . as _ bytes ()). unwrap (); 
stream . flush().unwrapO ; 

} 

リスト 20-3: ストリームに矮小な成功の HTTP レスポンスを書き込む 

新しい最初の行に成功したメッセージのデータを保持する response 変数を定義しています。そし 
て、 response に対して as_bytes を呼び出し、文字列データをバイトに変換します。 stream の write 
メソッドは、& [ u 8] を取り、接続に直接そのバイトを送信します。 

write 処理は失敗することもあるので、以前のように エラーの 結果には unwrap を使用します。今回 
も、実際のアプリでは、 エラー 処理をここに追加するでしょう。最後に flush は待機し、バイトが全 
て接続に書き込まれるまでプログラムが継続するのを防ぎます； TcpStream は内部にバッファーを保 
持して、元となる OS への呼び出しを最小化します。 

これらの変更とともに、コードを実行し、リクエストをしましょう。最早、端末にどんなデー 
夕も出力していないので、 Cargo からの出力以外には何も出力はありません。 Web ブラウザで 
127.0 .0.1:7878 をロードすると、エラーではなく空のページが得られるはずです。 HTTP リクエス 
卜とレスポンスを手で実装したばかりなのです！ 

20.1 .5 本物の HTML を返す 

空のページ以上のものを返す機能を実装しましょう。新しいファイル hello . html を src ディレク 
トリではなく、プロジェクトのルートディレクトリに作成してください。お好きなように HTML を 
書いてください；リスト 20-4 は、一つの可能性を示しています。 


ファイル名： hello.html 


CDOCTYPE html> 

<html lang="en"> 

<head> 

<meta charset="utf-8 H > 
<title>Hello!</title> 
</head> 

<body> 

く！ -- やあ ！ --> 
<hl>Hello!</hl> 

く！一一 Rust^ らやあ 一 -> 
<p>Hi from Rust く / p> 
</body> 

</html> 
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リスト 20-4: レスポンスで返すサンプルの HTML ファイル 

これは、ヘッドとテキストのある最低限の HTML5 ドキュメントです。リクエストを受け付けた際 
にこれをサーパから返すには、リスト 20-5 のように handl_e_connecti on を変更して HTML ファイ 
ルを読み込み、本体としてレスポンスに追加して送ります。 

ファイル名： src / main.rs 

# use std : :]〇: : prelude : 

# use std :: net : : TcpStream ; 
use std :: fs : : Fi le ; 

// -- snip -- 


fn handle _ connection (mut stream : rcpStream ) { 
let mut buffer = [0; 512]; 
stream , read (&mut buffer).unwrapO ; 

let mut file = File : : open (" hello . html ") .unwrapO ; 

let mut contents = Stri ng : : new (); 

file • read _ to _ stri ng(&mut contents).unwrapO ; 

let response = format ! ( " HTTP /1.1200 0 K \ r \ n \ r \ n {}" , contents ); 

stream , write ( response . as _ bytes ()) . unwrapO ; 
stream . flush().unwrapO ; 

} 


リスト 20-5: レスポンスの本体として hello.html の中身を送る 


先頭に行を追加して標準ライブラリの File をスコープに導入しました。ファイルを開き、中身を 
読み込むコードは、馴染みがあるはずです；リスト 12-4 で I/O プロジェクト用にファイルの中身を読 
み込んだ時に第12章で使用しましたね。 

次に format! でファイルの中身を成功したレスポンスの本体として追記しています。 

このコードを cargo run で走らせ、 127.0 .0.1:7878 をブラウザでロー ドしてください； HTML が 
描画されるのが確認できるはずです！ 

現時点では、 buffer 内のリクエストデータは無視し、無条件で HTML ファイルの中身を送り返し 
ているだけです。これはつまり、ブラウザで 127.0 .0.1:7878/something-else をリクエストして 
も、この同じ HTML レスポンスが得られるということです。我々のサーバはかなり限定的で、多く 
の' Web サーバとは異なっています。リクエストに基づいてレスポンスをカスタマイズし、/ への 合法 
なリクエストに対してのみ HTML ファイルを送り返したいです。 
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20.1 .6 リクエストにバリデーシヨンをかけ、選択的にレスポンスを返す 

現状、この Web サーバはクライアントが何を要求しても、このファイルの HTML を返します。 
HTML ファイルを返却する前にブラウザが/をリクエストしているか確認し、ブラウザが他のものを 
要求していたらエラーを返す機能を追加しましょう。このために、 handle^onnection をリスト 20-6 
のように変更する必要があります。この新しいコードは、/への要求がどんな見た目になるのか我々が 
知っていることに対して受け取ったリクエストの中身を検査し、 if と else ブロックを追加して、リ 
クエストを異なる形で扱います。 

フアイル名： src / main.rs 

# use std::io::prelude: 

# use std: : net: :TcpStream; 

# use std::fs:: File; 

// __snip-- 


fn handle _ connection (mut stream : rcpStream ) { 
let mut buffer = [0; 512]; 
stream , read (&mut buffer).unwrapO ; 

let get = b M GET / HTTP /1.1\ r \ n " ; 

if buffer . starts _ with ( get ) { 

let mut ti Le = File : : open (" hello . html ") .unwrapO ; 

let mut contents = Stri ng : : new (); 

file . read _ to _ stri ng(&mut contents ) .unwrapO ; 

let response = format ! (" HTTP /1.1200 0 K \ r \ n \ r \ n {}" , contents ); 


stream.write(response.as_bytes()).unwrapO; 
stream.flush() .unwrapO ; 

} else { 

// 何か他の要求 
// some other request 



リスト 20-6: リクエストをマッチさせ、/へのリクエストを他のリクエストとは異なる形で扱う 

まず、/リクエストに対応するデータを get 変数にハードコードしています。生のバイトをバッ 
ファーに読み込んでいるので、 b’"' バイト文字列記法を中身のデータの先頭に追記することで、 get 
をバイト文字列に変換しています。そして、 buffer が get のパイトから始まっているか確認します。 
もしそうなら、/への合法なリクエストを受け取ったことを意味し、これが、 HTML ファイルの中身 
を返す if ブロックで扱う成功した場合になります。 
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buffer が get のバイトで始まらないのなら、何か他のリクエストを受け取ったことになります。こ 
の後すぐ、 else ブロックに他のリクエストに対応するコードを追加します。 

さあ、このコードを走らせて 127.0 .0.1:7878 を要求してください； hello.html の HTML が得ら 
れるはずです。 127.0 .0.1:7878/something-else などの他のリクエストを行うと、リスト 20-1 や 
20-2 のコードを走らせた時に見かけた接続エラーになるでしょう。 

では、 else ブロックにリスト 20-7 のコードを追記して、ステータスコード404のレスポンスを返 
しましょう。これは、リクエストの中身が見つからなかったことを通知します。エンドユーザへのレ 
スポンスを示し、ページをブラウザに描画するよう、何か HTML も返します。 

フアイル名： src / main.rs 

# use std : :]〇: : prelude : 

# use std :: net : : TcpStream ; 

# use std :: fs :: File ; 

# fn handle _ connection (mut stream : TcpStream ) { 

# if true { 

// -- snip -- 

} else { 

let status.line = " HTTP /1.1404 NOT FOUND \ r \ n \ r \ n " ; 
let mut file = File : : open ("404. html ") . unwrap (); 
let mut contents = Stri ng : : new (); 

ti Le . read _ to _ stri ng(&mut contents ) . unwrapO ; 

let response = format ! ("{}{}" , status _ line , contents ); 

stream . write ( response . as _ bytes ()). unwrapO ; 
stream , flush (). unwrapO ; 

} 

# } 

リスト 20-7: / 以外の何かが要求されたら、ステータスコード404とエラーページで応答する 

ここでは、レスポンスにはステータスコード404と理由フレーズ not found のステータス行があ 
ります。それでもヘッダは返さず、レスポンスの本体は、ファイル 404.html の HTML になります。 
エラーページのために、 hello.html の隣に 404.html ファイルを作成する必要があります；今回も、 
ご自由にお好きな HTML にしたり、リスト 20-8 の例の HTML を使用したりしてください。 

ファイル名： 404 .html 


<!D0CTYPE html> 

<html lang="en"> 

<head> 

<meta charset="utf-8 H > 
<title>Hello!</title 〉 
</head> 
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< body > 

く！--ああ！ --> 

< hl > Oops ! </ hl > 

く！--すいません。要求しているものが理解できません --> 

< p > Sorry , I don't know what you're asking for .</ p > 

</ body > 

</ html > 

リスト 20-8： あらゆる 404 レスポンスでページが送り返す中身のサンプル 

これらの変更とともに、もう一度サーバを実行してください。127.0.0.1:7878を要求すると、 
hello . html の中身が返り、 127.0.0.1:7878/ foo などの他のリクエストには 404. html からのエ 

ラー HTML が返るはずです。 

20.1 .7 リファクタリングの触り 

現在、 if と else ブロックには多くの繰り返しがあります：どちらもファイルを読み、ファイルの 
中身をストリームに書き込んでいます。唯一の違いは、ステータス行とファイル名だけです。それら 
の差異を、ステータス行とファイル名の値を変数に代入する個別の if と else 行に引っ張り出して、 
コードをより簡潔にしましょう；そうしたら、それらの変数を無条件にコードで使用し、ファイルを 
読んでレスポンスを書き込めます。リスト 20-9 は、大きな if と else ブロックを置き換えた後の結 
果のコードを示しています。 

フアイル名： src / main.rs 

# use std :: io :: prelude : 

# use std : : net : : TcpStream ; 

# use std :: fs :: File ; 

// -- snip -- 

fn handle _ connection (mut stream : TcpStream ) { 

林 let mut buffer = [0; 512]; 

# stream , read (&mut buffer ) .unwrapO ; 

# 

# let get = b"GET / HTTP /1.1\ r \ n " ; 

// __ snip __ 

let ( status _ line , filename ) = if buffer . starts _ with ( get ) { 

(" HTTP /1.1200 0 K \ r \ n \ r \ n " , " hello . html ") 

} else { 

(" HTTP /1.1404 NOT F 0 UND \ r \ n \ r \ n " , M 404. html u ) 

}； 

let mut ti le = File : : open ( filename ) .unwrapO ; 
let mut contents = Stri ng : : new (); 

ti le . read _ to _ stri ng(&mut contents ). unwrapO ; 
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let response = rormat ! ("{}{}" , status . nne , contents ); 

stream . write ( response . as _ bytes ()). unwrapO ; 
stream . flush().unwrapO ; 

} 

リスト 20-9： 2 つの場合で異なるコードだけを含むように、 if と else ブロックをリファクタリン 
グする 

これで、 if と else ブロックは、タプルにステータス行とファイル名の適切な値を返すだけになり 
ました；それから、分配を使用してこれら2つの値を第18章で議論したように、 let 文のパターンで 
status _ line と filename に代入しています。 

前は童複していたコードは、今では if と else ブロックの外に出て、 status _ line と filename 変 
数を使用しています。これにより、2つの場合の違いがわかりやすくなり、ファイル読み取りとレス 
ポンス記述の動作法を変更したくなった際に、1箇所だけコードを更新すればいいようになったこと 
を意味します。リスト 20-9 のコードの振る舞いは、リスト 20-8 と同じです。 

素晴らしい！もう、およそ40行の Rust コードで、あるリクエストには中身のあるページで応答 
し、他のあらゆるリクエストには404レスポンスで応答する単純な Web サーバができました。 

現状、このサーバは、シングルスレッドで実行されます。つまり、1回に1つのリクエストしか捌 
けないということです。何か遅いリクエストをシミュレーシヨンすることで、それが問題になる可能 
性を調査しましょう。それから1度にサーバが複数のリクエストを扱えるように修正します。 

20.2 シングルスレツドサーバをマルチスレツド化する 

現状、サーバはリクエストを順番に処理します。つまり、最初の接続が処理し終わるまで、2番目の 
接続は処理しないということです。サーバが受け付けるリクエストの量が増えるほど、この連続的な 
実行は、最適ではなくなるでしょう。サーバが処理するのに長い時間がかかるリクエストを受け付け 
たら、新しいリクエストは迅速に処理できても、続くリクエストは長いリクエストが完了するまで待 
たなければならなくなるでしょう。これを修正する必要がありますが、まずは、実際に問題が起こっ 
ているところを見ます。 

20.2.1 現在のサーバの実装で遅いリクエストをシミュレーシヨンする 

処理が遅いリクエストが現在のサーバ実装に対して行われる他のリクエストにどう影響するかに目 
を向けます。リスト 20-10 は、応答する前に5秒サーバをスリープさせる遅いレスポンスをシミュ 
レーシヨンした/ sleep への リクエストを扱う実装です。 

フアイル名： src / main.rs 


use std :: thread ; 
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use std :: time: : Duration; 

# use std: :] 〇 :: prelude: 

# use std: : net: :TcpStream; 

# use std :: fs: : File; 

// --snip-- 

fn handle_connection (mut stream: TcpStream) { 

# let mut buffer = [0; 512]; 

# stream, read (&mut buffer) .unwrapO ; 

// --snip__ 

let get = b"GET / HTTP/1.l\r\n" ; 

let sleep = b"GET /sleep HTTP/1.l\r\n" ; 

let (status_line, filename) = if buffer.starts_with(get) { 

("HTTP/l.l200 0K\r\n\r\n M , "hello.html") 

} else if buffer.starts_with(sleep) { 

thread :: sleep (Du rati on :: from_secs(5)); 

("HTTP/l.l200 0K\r\n\r\n" , "hello.html") 

} else { 

("HTTP/l.l404 NOT FOUND\r\n\r\n" , "404.html") 

}； 

// --snip-- 

} 

リスト 20-10: /sleep を認識して 5 秒間スリーブすることで遅いリクエストをシミュレーション 
する 

このコードはちょっと汚いですが、シミュレーション目的には十分です。2畨目のリクエスト sleep 
を作成し、そのデータをサーバは認識します。 if ブロックの後に else if を追加し、 /sleep への 
リクエストを確認しています。そのリクエストが受け付けられると、サーバは成功の HTML ページ 
を描画する前に5秒間スリーブします。 

我々のサーバがどれだけ基礎的か見て取れます：本物のライブラリは、もっと冗長でない方法で複 
数のリクエストの認識を扱うでしょう！ 

cargo run でサーバを開始してください。それから 2 つブラウザのウインドウを開いてください： 1 

つは、 http://localhost:7878/ 用、そしてもう 1 つは http://localhost:7878/sleep 用です。以前 
のように/ URI を数回入力したら、素早く応答するでしょう。しかし、 /sleep を入力し、それから/を 
ロードしたら、 sleep がロードする前にきっかり5秒スリープし終わるまで、/は待機するのを目撃 
するでしょう。 

より多くのリクエストが遅いリクエストの背後に回ってしまうのを回避するよう Web サーバが動 
く方法を変える方法は複数あります；これから実装するのは、スレッドプールです。 
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20.2 .2 スレッドプールでスループットを向上させる 

スレッドプールは、待機し、タスクを処理する準備のできた一塊りの大量に生成されたスレッドで 
す。プログラムが新しいタスクを受け取ったら、プールのスレッドのどれかをタスクにあてがい、そ 
のスレッドがそのタスクを処理します。プールの残りのスレッドは、最初のスレッドが処理中にやっ 
てくる他のあらゆるタスクを扱うために利用可能です。最初のスレッドがタスクの処理を完了したら、 
アイドル状態のスレッドプールに戻り、新しいタスクを処理する準備ができます。スレッドプールに 
より、並行で接続を処理でき、サーバのスループットを向上させます。 

プール内のスレッド数は、小さい数字に制限し、 DoS(Denial of Service ; サービスの拒否）攻撃か 
ら保護します；リクエストが来た度に新しいスレッドをプログラムに生成させたら、1000万リクエス 
卜をサーバに行う誰かが、サーバのリソースを使い尽くし、リクエストの処理を停止に追い込むこと 
で、大混乱を招くことができてしまうでしょう。 

無制限にスレッドを大量生産するのではなく、プールに固定された数のスレッドを待機させます。 
リクエストが来る度に、処理するためにプールに送られます。プールは、やって来るリクエストの 
キューを管理します。プールの各スレッドがこのキューからリクエストを取り出し、リクエストを処 
理し、そして、別のリクエストをキューに要求します。この設計により、 n リクエストを並行して処理 
でき、ここで n はスレッド数です。各スレッドが実行に時間のかかるリクエストに応答していたら、 
続くリクエストはそれでも、キュー内で待機させられてしまうこともありますが、その地点に到達す 
る前に扱える時間のかかるリクエスト数を増加させました。 

このテクニックは、 Web サーバのスループットを向上させる多くの方法の1 つに 過ぎません。探 
究する可能性のある他の選択肢は、 fork / join モデルと、 シングルスレッ ドの非同期 I / O モデルです。 
この話題にご興味があれば、他の解決策についてもっと読み、 Rust で実装を試みることができます; 
Rust のような低 レベル 言語であれば、これらの選択肢全部が可能なのです。 

スレッドプールを実装し始める前に、プールを使うのはどんな感じになるはずなのかに ついて 語り 
ましょう。コードの設計を試みる際、クライアントのインターフヱイスをまず書くことは、設計を導 
く手助けになることがあります。呼び出したいように構成されるよう、コードの API を記述してくだ 
さい；そして、機能を実装してから公開 API の設計をするのではなく、その構造内で機能を実装して 
ください。 

第12章のプロジェクトで TDD を使用したように、ここでは Compiler Driven Development (コ 
ンパイラ駆動開発）を使用します。欲しい関数を呼び出すコードを書き、それからコンパイラの出す 
エラーを見てコードが動くように次に何を変更すべきかを決定します。 

20.2.2.1 各リクエストに対してスレッドを立ち上げられる場合のコードの構造 

まず、全接続に対して新しいスレッドを確かに生成した場合にコードがどんな見た目になるかを探 
究しましょう。先ほど述べたように、無制限にスレッドを大量生産する可能性があるという問題のた 
め、これは最終的な計画ではありませんが、開始点です。リスト 20-11 は、新しいスレッドを立ち上 
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げて for ループ内で各ストリームを扱うために main に行う変更を示しています。 
フアイル名： src / main.rs 

# use std :: thread ; 

# use std: :] 〇 : :prelude: 

# use std::net: :TcpListener ; 

# use std: : net: :TcpStream; 

# 

fn main() { 

let listener = TcpListener :: bind ("127. 0.0.1:7878") . unwrap() ; 

for stream in listener.incoming() { 
let stream = stream.unwrapO ; 

thread :: spawn(|| { 

handle_connection(stream); 

})； 

} 

} 

# fn handle_connection (mut stream: TcpStream) {} 


リスト 20-11: 各ストリームに対して新しいスレッドを立ち上げる 

第16章で学んだように、 thread : : spawn は新しいスレッドを生成し、それからクロージャ内のコ^一 
ドを新しいスレッドで実行します。このコードを実行してブラウザで/ sleep をロードし、それからも 
う2つのブラウザのタブで/をロードしたら、確かに/へのリクエストは、 /sleep が完了するのを待 
機しなくても済むことがわかるでしょう。ですが、前述したように、無制限にスレッドを生成するこ 
とになるので、これは最終的にシステムを参らせてしまうでしょう。 

20.2.2.2 有限数のスレッド用に似たインターフェイスを作成する 

スレッドからスレッドプールへの変更に API を使用するコードへの大きな変更が必要ないように、 
スレッドプールには似た、馴染み深い方法で動作してほしいです。リスト 20-12 は、 thread : : spawn 
の代わりに使用したい ThreadPool 構造体の架空のインターフェイスを表示しています。 

フアイル名： src / main.rs 

# use std :: thread ; 

# use std :: io :: prelude : 

# use std : : net : : TcpLi stener ; 

# use std : : net : : TcpStream ; 

# struct ThreadPool ; 

# impl ThreadPool { 

# fn new ( size : u 32) -> ThreadPool { ThreadPool } 

# fn execute < F > (& self ， f : F ) 

# where F : FnOnce () + Send + 'static {} 
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fn mann() i 

let listener = TcpListener: : bind ("127.0.0.1:7878") .unwrap(); 
let pool=ThreadPool: : new(4); 

for stream in listener. i ncoming() { 
let stream = stream.unwrapO ; 


pool.execute(|| { 

handle_connection(stream); 

})； 

} 

} 

# fn handle_connection (mut stream: TcpStream) {} 


リスト 20-12： ThreadPool の理想的なインターフェイス 

ThreadPool: :new を使用して設定可能なスレッド数で新しいスレッドプールを作成し、今回の場合 
は4です。それから for ループ内で、 pool, execute は、プールが各ストリームに対して実行すべきク 
ロージャを受け取るという点で、 thread : : spawn と似たイ ンターフェイ スです。 pool.execute を実装 
する必要があるので、これはクロージャを取り、実行するためにプール内のスレッドに与えます。こ 
のコードはまだコンパイルできませんが、コンパイラがどう修正したらいいかガイドできるように試 
してみます。 

20.2.2.3 コンパイラ駆動開発で ThreadPool 構造体を構築する 

リスト 20-12 の変更を src / main . rs に行い、それから開発を駆動するために cargo check からの 
コンパイラエラーを 活用しましょう。こちらが得られる最初の エラーです： 


5 cargo check 

Compiung hello v 0.1.0 (tt ie :/// projects / nello ) 
error [ E 0433] : failed to resolve . Use of undeclared type or module ' ThreadPool ' 
(エラー： 解決に失敗しました。未定義の型またはモジ ュー ル' ThreadPool ' を使用してい 
ます） 

-- > src \ main . rs :10:16 

I 

10 | let pool = ThreadPool : : new (4); 

| aaaaaaaaaaaaaaa y se 0 f undeclared type or module 

' ThreadPool ' 

error : aborting due to previous error 

よろしい！このエラーは ThreadPool 型かモジュールが必要なことを教えてくれているので、今構築 
します。 ThreadPool の実装は、 Web サーバが行う仕事の種類とは独立しています。従って、 hello 
クレートをバイナリクレートからライブラリクレートに切り替え、 ThreadPool の実装を保持させま 
しょう。ライブラリクレートに変更後、個別のスレッドプールライブラリを Web V クエストを提供 
するためだけではなく、スレッドプールでしたいあらゆる作業にも使用できます。 
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以下を含む src/lib.rs を生成してください。これは、現状存在できる最も単純な ThreadPool の定 
義です： 

ファイル名： src / lib.rs 

pub struct ThreadPool; 


それから新しいディレクトリ、 src/bin を作成し、 src/main.rs に根付くバイナリクレートを 
src/bin/main.rs に移動してください。そうすると、ライブラリクレートが hello ディレクトリ内 
で主要クレートになります；それでも、 cargo run で src/bin/main.rs のバイナリを実行することは 
できます。 main.rs ファイルを移動後、編集してライブラリクレートを持ち込み、以下のコードを 
src/bin/main.rs の先頭に追記して ThreadPool をスコープに導入してください： 

ファイル名： src / bm / main.rs 

extern crate hello; 
use hello::ThreadPooi; 


このコードはまだ動きませんが、再度それを確認して扱う必要のある次のエラーを手に入れま 
しよう： 


$ cargo check 

Compiling hello v0. 1 .0 (file:///proiects/he lIo) 
error[E0599] : no function or associated item named 'new' found for type 
'hello::ThreadPooL in the current scope 

(エラー： 現在のスコープで型、 hello : : ThreadPool' の関数または関連アイテムに ' new ' と 
いうものが見つかりません） 

-- > src/bin/main•rs :13:16 


I 

13 | 


let pool=ThreadPool::new ⑷； 


| A A I 

'hello::ThreadPool' 


function or associated item not found i n 


このエラーは、次に、 ThreadPool に対して new という関連関数を作成する必要があることを示唆し 
ています。また、 new には 4 を引数として受け入れる引数1つがあり、 ThreadPool インスタンスを返 
すべきということも知っています。それらの特徴を持つ最も単純な new 関数を実装しましょう： 

ファイル名： src / lib.rs 

pub struct ThreadPool; 

impl ThreadPool { 

pub fn new(size: usize) 

ThreadPool 


} 


} 


-> ThreadPool{ 
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size 引数の型として、 usize を選択しました。何故なら、マイナスのスレッド数は、何も筋が通ら 
ないことを知っているからです。また、この4をスレッドのコレクションの要素数として使用し、第 
3章の「整数型」節で議論したように、これは usize のあるべき姿であることも知っています。 

コードを再度確認しましょう： 


$ cargo check 

Compiling hello v0.1.0 (tn ie:///pro]ects/hello; 
warning: unused variable: 'size' 

(警告：未使用の変数： 'size') 

--> src/lib.rs:4:16 

I 

4 | pub fn new(size : usize) -> ThreadPool{ 

| A A A A 

I 

=note : #[warn(unused_variables)] on by default 
=note : to avoid this warning, consider using '_size' instead 

error[E0599] : no method named 'execute' found for type 'hello::ThreadPool in 
the current scope 
--> sre/bin/main.rs:18:14 

I 

18 | pool.execute(|| { 

| A A A A A A A 

今度は、警告とエラーが出ました。一時的に警告は無視して、 ThreadPool に execute メソッドがな 
いためにエラーが発生しました。「有限数のスレッド用に似たインターフェイスを作成する」節で我々 
のスレッドプールは、 thread : : spawn と似たインターフェイスにするべきと決定したことを思い出し 
てください。さらに、 execute 関数を実装するので、与えられたクロージャを取り、実行するように 
プールの待機中のスレッドに渡します。 

ThreadPool に execute メソッドをクロージャを引数として受け取るように定義します。第13章の 
「ジェネリック引数と Fn トレイトを使用してクロージャを保存する」節から、3つの異なるトレイト 
でクロージャを引数として取ることができることを思い出してください： Fn 、 FnMut , FnOnce です。 
ここでは、どの種類のクロージャを使用するか決定する必要があります。最終的には、標準ライブラリ 
の thread : : spawn 実装に似たことをすることがわかつているので、 thread : : spawn のシグニチャで引 
数にどんな境界があるか見ることができます。ドキュメンテーションは、以下のものを示しています: 


pub fn spawn く F ， T >( f : F ) -> 3 oi nHandle < T > 
where 

F : FnOnce () - > T + Send + ’ static ， 
T : Send + 'static 


F 型引数がここで関心のあるものです； T 型引数は戻り値と関係があり、関心はありません 。 spawn 
は、 F のトレイト境界として FnOnce を使用していることが確認できます。これはおそらく、我々が欲 



第 20 章最後のプロジェクト：マルチスレッドの' Web サーバを構築する 


515 


しているものでもあるでしょう。というのも、最終的には execute で得た引数を spawn に渡すからで 
す。さらに FnOnce は使用したいトレイトであると自信を持つことができます。リクエストを実行す 
るスレッドは、そのリクエストのクロージャを1回だけ実行し、これは FnOnce の Once に合致するか 
らです。 

F 型引数にはまた、トレイト境界の Send とライフタイム境界の 1 static もあり、この状況では有用 
です：あるスレッドから別のスレッドにクロージャを移動するのに Send が必要で、スレッドの実行に 
どれくらいかかるかわからないので、 'static も必要です。 ThreadPool にこれらの境界のジェネリッ 
クな型 F の引数を取る execute メソッドを生成しましょう： 

ファイル名： src / lib.rs 

# pub struct ThreadPool; 
impl ThreadPool { 

// --snip-- 


pub fn execute<F> (&self ， f: F) 
where 

F : FnOnce() + Send + 1 static 

{ 



それでも、 FnOnce の後に （） を使用しています。この FnOnce は引数を取らず、値も返さない クロー 
ジャを表すからです。関数定義同様に、戻り値の型はシグニチャから省略できますが、引数がなくて 
も、カツコは必要です。 

またもや、これが execute メソツドの最も単純な実装です：何もしませんが、コードがコンパイル 
できるようにしようとしているだけです。再確認しましょう： 


$ cargo check 

Compiling heLLo v0.1.0 (file : ///proiects/heLlo) 
warning: unused variable: 'size' 

--> src/lib.rs:4:16 

I 

4 | pub fn new(size: usize) -> ThreadPool{ 

| A A A A 

I 

=note : #[warn(unused_variables)] on by default 
=note : to avoid this warning, consider using '_size' instead 

warning: unused variable: ' f' 

--> src/lib.rs:8:30 

I 

8 | pub fn execute<F>(&self, f: F) 

I A 

I 

=note : to avoid this warning, consider using '_f' instead 
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これで警告を受け取るだけになり、 コンパイル できるようになりました！しかし 、 cargo run を試 
して、ブラウザでリクエストを行うと、章の冒頭で見かけたエラーがブラウザに現れることに注意し 
てください。ライブラリは、まだ実際に execute に渡されたクロージャを呼び出していないのです！ 

注釈： Haskell や Rust などの厳密なコンパイラがある言語についての格言として「コードが 
コンパイルできたら、動作する」というものをお聴きになったことがある可能性があります。 
ですが、この格言は普遍的に当てはまるものではありません。このプロジェクトはコンパイル 
できますが、全く何もしません！本物の完璧なプロジェクトを構築しようとしているのなら、 
ここが単体テストを書き始めて、コードがコンパイルでき、かつ欲しい振る舞いを保持してい 
ることを確認するのに良い機会でしょう。 

20.2.2.4 new でスレッド数を検査する 

new と execute の引数で何もしていないので、警告が出続けます。欲しい振る舞いでこれらの関数 
の本体を実装しましょう。まずはじめに、 new を考えましょう。先刻、 size 引数に非負整数型を選択 
しました。負のスレッド数のプールは、全く道理が通らないからです。しかしながら、0スレッドの 
プールも全く意味がわかりませんが、0も完全に合法な usize です。 ThreadPool インスタンスを返す 
前に size が0よりも大きいことを確認するコードを追加し、リスト 20-13 に示したように、 assert ! 
マクロを使用することで0を受け取った時にプログラムをパニックさせます。 

ファイル名： src/lib.rs 


# pub struct ThreadPool; 
imp l ThreadPool i 

III 新しい ThreadPool を生成する。 

III 

III size が プールの ス レツ ド数です。 

III 

III #パニック 

III 

III size が 0 なら 、' new' 関数はパニツクします。 

III 

III Create a new ThreadPool. 

Ill 

III The size is the number of threads in the pool. 

Ill 

III # Panics 

III 

III The 'new' function will panic if the size is zero. 
pub fn new(size: usize) -> ThreadPool{ 
assert! (size > 0); 

ThreadPool 

} 
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// -- snip __ 

} 

リスト 20-13: ThreadPool :: new を実装して size が 0 ならパニックする 

doc comment で ThreadPool にドキュメンテーションを追加しました。第 14 章で議論したよう 
に、関数がパニックすることもある場面を声高に叫ぶセクションを追加することで、いいドキュメン 
テーションの実践に倣（なら）っていることに注意してください。試しに cargo doc -- open を実行 
し、 ThreadPool 構造体をクリックして、 new の生成されるドキュメンテーションがどんな見た目か確 
かめてください！ 

ここでしたように assert ! マクロを追加する代わりに、リスト 12-9 の I/O プロジェクトの Config 
:: new のように、 new に Result を返させることもできるでしょう。しかし、今回の場合、スレッドな 
しでスレッドプールを作成しようとするのは、回復不能なエラーであるべきと決定しました。野心を 
感じるのなら、以下のシグニチャの new も書いてみて、両者を比較してみてください： 

pub rn new ( size : usize ) -> Result < ThreadPool , PooLCreationError > { 


20.2.2.5 スレッドを格納するスペースを生成する 
今や、プールに格納する合法なスレッド数を知る方法ができたので、 ThreadPool 構造体を返す前に 
スレッドを作成して格納できます。ですが、どのようにスレッドを「格納」するのでしょうか？もう 
~■度、 thread : : spawn シグニチヤを眺めてみましょう： 


pub fn spawn く F ， T >( f : F ) -> 3 oi nHandle < T > 
where 

F : FnOnce () - > T + Send + ' static , 

T : Send + ’static 

spawn 関数は、 JoinHandle く T > を返し、ここで T は、クロージャが返す型です。試しに同じように 
コ oinHandle を使ってみて、どうなるか見てみましょう。我々の場合、スレッドプールに渡すクロー 
ジャは接続を扱い、何も返さないので、 T はユニット型 （） になるでしょう。 

リスト 20-14 のコードはコンパイルできますが、まだスレッドは何も生成しません 。 ThreadPool 
の定義を変更して、 thread : :] oinHandle <()> インスタンスのベクタを保持し、 size キャパシティの 
ベクタを初期化し、スレッドを生成する何らかのコードを実行する for •ループを設定し、それらを含 
む ThreadPool インスタンスを返します。 


フアイル名： src/lib.rs 
use std :: thread ; 


pub struct inreadPool { 
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threads : Vec<thread :: JoinHandle< () >> . 

} 


impl ThreadPool { 

// -- snip -- 

pub fn new ( size : usize ) -> ThreadPool { 

assert! (size > 0); 

let mut threads = Vec : : with _ capacity ( size ) ; 

for _ in 0 .. size { 

// スレッドを生成してベクタに格納する 

// create some threads and store them in the vector 

} 

ThreadPool { 
threads 

} 

} 

// -- snip -- 

} 

リスト 20-14: ThreadPool にスレッドを保持するべクタを生成する 

ライブラリクレート内で std : : thread をスコープに導入しました。 ThreadPool のべクタの要素の 
型として、 thread : : JoinHandle を使用しているからです。 

一旦、合法なサイズを受け取ったら、 ThreadPool は size 個の要素を保持できる新しいベクタを生 
成します。この本ではまだ、 with_capacity 関数を使用したことがありませんが、これは Vec::new と 
同じ作業をしつつ、重要な違いがあります：ベクタに予めスペースを確保しておくのです。ベクタに 
size 個の要素を格納する必要があることはわかっているので、このメモリ確保を前もってしておく 
と、 Vec : :new よりも少しだけ効率的になります。 Vecxnew は、要素が挿入されるにつれて、自身の 
サイズを変更します。 

再び cargo check を実行すると、もういくつか警告が出るものの、成功するはずです。 

20.2.2.6 ThreadPool からスレッドにコードを送信する責任を負う Worker 構造体 

リスト 20-14 の for ループにスレッドの生成に関するコメントを残しました。ここでは、実際にス 
レッドを生成する方法に目を向けます。標準ライブラリはスレッドを生成する手段として thread :: 
spawn を提供し、 thread : : spawn は、生成されるとすぐにスレッドが実行すべき何らかのコードを得 
ることを予期します。ところが、我々の場合、スレッドを生成して、後ほど送信するコードを待機し 
てほしいです。標準ライブラリのスレッドの実装は、それをするいかなる方法も含んでいません；そ 
れを手動で実装しなければなりません。 

この新しい振る舞いを管理するスレッドと ThreadPool 間に新しいデータ構造を導入することでこ 
の振る舞いを実装します。このデータ構造を Worker と呼び、プール実装では一般的な用語です。レ 
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ストランのキッチンで働く人々を思い浮かべてください：労働者は、お客さんからオーダーが来るま 
で待機し、それからそれらのオーダーを取り、満たすことに責任を負います。 

スレッドプールに] oi nHanlde < () >インスタンスのベクタを格納する代わりに、 Worker 構造体のイ 
ンスタンスを格納します。各 Worker が単独の] oinHandle <()> インスタンスを格納します。そして、 
Worker に実行するコードのクロージャを取り、既に走っているスレッドに実行してもらうために送信 
するメソッドを実装します。ログを取ったり、デバッグする際に プールの 異なるワーカーを区別でき 
るように、各ワーカーに id も付与します。 

ThreadPool を生成する際に発生することに以下の変更を加えましょう。このように Worker をセッ 
トアップした後に、スレッドにクロージャを送信するコードを実装します： 

1. id と 3 oinHandle <()> を保持する Worker 構造体を定義する。 

2. ThreadPool を変更し、 Worker インスタンスのベクタを保持する。 

3. id 番号を取り、 id と空のクロージャで大量生産されるスレッドを保持する Worker インスタン 
スを返す Worker : : new 関数を定義する。 

4. ThreadPool: : new で for ループカウンタを使用して id を生成し、その id で新しい Worker を 
生成し、ベクタにワーカーを格納する。 

挑戦に積極的ならば、リスト 20-15 のコードを見る前にご自身でこれらの変更を実装してみてくだ 
さい。 

いいですか？こちらが先ほどの変更を行う 1 つの方法を行ったリスト 20-15 です。 

ファイル名： src / lib.rs 

use std :: thread ; 

pub struct ThreadPoo l { 
workers : Vec < Worker >, 

} 


impl ThreadPool { 

// snip __ 

pub fn new ( si ze : usize ) -> ThreadPool { 
assert! (size > 0); 

let mut workers = Vec : : with _ capacity ( size ) ; 

for id in 0 . .size { 

workers . push ( Worker :: new ( id ) ); 

} 


ThreadPool { 
workers 

} 

} 

II -- snip -- 
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struct Worker { 
id : usize . 

thread : thread :: 3 oinHandle < u >? 

} 

impl Worker { 

fn new ( id : usize ) -> Worker { 

let thread = thread :: spawn (|| {}); 

Worker { 
id , 

thread , 



リスト 20-15: ThreadPool を変更してスレッドを直接保持するのではなく、 Worker インスタンス 
を保持する 

ThreadPool のフィールド名を threads から workers に変更しました 。] oi nHandle < () >インスタ 
ンスではなく、 Worker インスタンスを保持するようになったからです。 for ループのカウンタを 
Worker :: new への引数として使用し、それぞれの新しい Worker を workers というべクタに格納し 
ます。 

外部のコード (src/bin/main.rs のサーバなど）は、 ThreadPool 内で Worker 構造体を使用してい 
ることに関する実装の詳細を知る必要はないので、 Worker 構造体とその new 関数は非公開にしていま 
す。 Worker : : new 関数は与えた id を使用し、空のクロージャを使って新しいスレッドを立ち上げるこ 
とで生成される ] oi _ nHandle <()> インスタンスを格納します。 

このコードはコ ン パイ ルで き、 ThreadPool :: new への引数として指定した数の Worker イ ンスタン 
スを格納します。ですがそれでも、 execute で得るクロージャを処理してはいません。次は、それを 
する方法に目を向けましょう。 

20.2.2.7 チヤンネル経由でスレッドにリクエストを送信する 

さて、 thread : : spawn に与えられたクロージャが確かに何もしない問題に取り組みましょう。現在、 
execute メソッドで実行したいクロージャを得ています。ですが、 ThreadPool の生成中、 Worker そ 
れぞれを生成する際に、実行するクロージャを thread : : spawn に与える必要があります。 

作ったばかりの Worker 構造体に ThreadPool が保持するキューから実行するコードをフェッチし 
て、そのコードをスレッドが実行できるように送信してほしいです。 

第16章でこのユースケースにびったりであろうチヤンネル （2 スレッド間コミュニケーション 
をとる単純な方法）について学びました。チャンネルをキューの仕事として機能させ、 execute は 
ThreadPool から Worker インスタンスに仕事を送り、これが仕事をスレッドに送信します。こちらが 
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計画です： 

1. ThreadPool はチャンネルを生成し、チャンネルの送信側に就く。 

2. Worker * それぞれは、チャンネルの受信側に就く。 

3. チャンネルに送信したいクロージャを保持する亲斤しい] ob 構造体を生成する。 

4. execute メソッドは、実行したい仕事をチャンネルの送信側に送信する。 

5. スレッド内で、 Worker はチャンネルの受信側をループし、受け取ったあらゆる仕事のクロー 
ジャを実行する。 

ThreadPool :: new 内でチャンネルを生成し、 ThreadPool インスタンスに送信側を保持することか 
ら始めましょう。リスト 20-16 のようにですね。今の所、 ] ob 構造体は何も保持しませんが、チャン 
ネルに送信する種類の要素になります。 

ファイル名： src / lib.rs 

# use std :: thread ; 

// -- snip -- 

use std :: sync :: mpsc ; 


pub struct I ' nreadPool { 
workers : Vec < Worker >, 
sender : mpsc : : Sender <3 ob > , 

} 


struct Job ; 

impl ThreadPool { 

// -- snip -- 

pub fn new ( size : usize ) -> ThreadPool { 
assert! (size > 0); 

let ( sender , receiver ) = mpsc :: channel (); 

let mut workers = Vec : : with _ capacity ( size ) ; 

for id in 0 . .size { 

workers . push ( Worker :: new ( id ) ); 

} 

ThreadPool { 
workers , 
sender , 

} 

} 

// -- snip -- 

} 

# 

# struct Worker { 

# id : usize , 
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# thread : thread : : JoinHandle < () >, 

# } 

# 

# impl Worker { 

# fn new ( id : usize ) -> Worker { 

# let thread = thread :: spawn (|| {}); 

# 

# Worker { 

# id , 

# thread , 

# } 

# } 

# } 

リスト 20-18: ThreadPool を変更して] ob インスタンスを送信するチヤンネルの送信側を格納する 

ThreadPool: : new 内で新しいチヤンネルを生成し、プールに送信側を保持させています。これはコ 
ンパイルに成功しますが、まだ警告があります。 

スレッドプールがワーカーを生成する際に各ワーカーにチャンネルの受信側を試しに渡してみま 
しょう。受信側はワーカーが大量生産するスレッド内で使用したいことがわかっているので、クロー 
ジャ内で receiver 引数を参照します。リスト 20-17 のコードはまだ完璧にはコンパイルできません。 

ファイル名： src / lib.rs 

impl ThreadPool { 

// —— snip __ 

pub fn new ( si ze : usize ) -> ThreadPool i . 
assert! (size > 0); 

let ( sender , receiver ) = mpsc :: channel (); 
let mut workers = Vec : : with _ capacity ( size ) ; 
for id in 0 . .size { 

workers . push ( Worker :: new ( id , receiver )); 

} 

ThreadPool { 
workers , 
sender , 

} 

} 

// snip __ 

} 

// --snip 
impl Worker { 

fn new ( id : usize , receiver : mpsc : : Recei ver <3 ob >) -> Worker { 
let thread = thread :: spawn (|| { 
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})； 


receiver; 


Worker { 
id, 

thread, 



リスト 20-17: チャンネルの受信側をワーカーに渡す 

多少些細で単純な変更を行いました：チャンネルの受信側を Worker: : new に渡し、それからクロー 
ジャの内側で使用しています。 

このコードのチェックを試みると、このようなエラーが出ます： 


$ cargo check 

Compiling hello v0.1.0 (file:///proiects/heLlo) 
error[E0382] : use of moved value: 'receiver' 

--> src/lib.rs:27:42 


27 


| workers•push(Worker::new い d ， 

I 

previous iteration of loop 


receiver)); 

aaaaaaaa value moved here in 


=note : move occurs because 'receiver' has type 

'std: : sync: : mpsc: : Receiver<3ob>', which does not implement the 'Copy' trait 


このコードは、 receiver を複数の Worker インスタンスに渡そうとしています。第16章を思い出 
すように、これは動作しません： Rust が提供するチャンネル実装は、複数の生成者、単独の消費者 
です。要するに、チャンネルの消費側をクローンするだけでこのコードを修正することはできませ 
ん。たとえできたとしても、使用したいテクニックではありません；代わりに、全ワーカー間で単独 
の receiver を共有することで、スレッド間に仕事を分配したいです。 

さらに、チャンネルキューから仕事を取り出すことは、 receiver を可変化することに関連するの 
で、スレッドには、 receiver を共有して変更する安全な方法が必要です；さもなくば、競合状態に陥 
る可能性があります（第16章で講義しました)。 

第16章で議論したスレッド安全なスマートポインタを思い出してください：複数のスレッドで所 
有権を共有しつつ、スレッドに値を可変化させるためには、 Arc<Mutex<T>> を使用する必要がありま 
す。 Arc 型は、複数のワーカーに受信者を所有させ、 Mutex により、 1 度に受信者から 1 つの仕事を 
たった1つのワーカーが受け取ることを保証します。リスト 20-18 は、行う必要のある変更を示して 
います。 


ファイル名： src / lib.rs 


# use std :: tnread ; 
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# use std :: sync :: mpsc ; 
use std :: svnc :: Arc ; 
use std :: svnc :: Mutex ; 
// __ snip 


# pub struct ThreadPool i 

# workers : Vec < Worker >, 

# sender : mpsc : : Sender 00 b > , 

# } 

# struct Job ; 

# 


impl ThreadPool { 

// --snip 

pub fn new (si ze : usize) -> ThreadPool{ 
assert! (size > 0); 

let (sender, receiver) = mpsc :: channel(); 
let receiver = Arc: :new (Mutex: : new(receiver)); 
let mut workers = Vec: : with_capacity (size) ; 
for id in 0. .size { 

workers.push(Worker :: new (id, Arc: :clone(&receiver))); 

} 


ThreadPool { 
workers , 
sender , 



// -- snip __ 

} 

# struct Worker { 

# id : usize , 

# thread : thread :: JoinHandle < ()>, 

# } 

# 

impl Worker { 

fn new ( id : usize , receiver : Arc く Mutex < mpsc : : Receiver 00 b >>>) -> Worker { 
// -- snip -- 

# let thread = thread :: spawn (|| { 

# receiver ; 

# »； 

# 

# Worker { 

# id , 

# thread , 

# 


} 


} 


} 
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リスト 20-18: Arc と Mutex を使用してワーカー間でチャンネルの受信側を共有する 

ThreadPool :: new で、チャンネルの受信側を Arc と Mutex に置いています。新しいワーカーそれぞ 
れに対して、 Arc をクローンして参照カウントを跳ね上げているので、ワーカーは受信側の所有権を 
共有することができます。 

これらの変更でコードはコンパイルできます！ゴールはもうすぐそこです！ 

20.2.2.8 execute メソッドを実装する 

最後に ThreadPool に execute メソッドを実装しましょう。； lob も構造体から execute が受け取る 
クロージャの型を保持するトレイトオブジェクトの型エイリアスに変更します。第19章の「型エイ 
リアスで型同義語を生成する」節で議論したように、型エイリアスにより長い型を短くできます。リ 
スト 20-19 をご覧ください。 

ファイル名： src / lib.rs 

// --snip-- 

# pub struct ThreadPool{ 

# workers : Vec<Worker>, 

# sender: mpsc: : Sender< Job>, 

# } 

# use std :: sync :: mpsc; 

# struct Worker {} 


type Job = Box<FnOnce() + Send + 'static 〉； 

impl ThreadPool{ 

// --snip-- 

pub fn execute<F> (&self , f: F) 
where 

F : FnOnce() + Send + ’static 

{ 

let job = Box :: new(f); 

self . sender. send (job) . unwrapO ; 



// -- snip -- 

リスト 20-19： 各クロージャを保持する Box に対して ] 0b 型エイリアスを生成し、それからチャン 
ネルに仕事を送信する 

execute で得たクロージャを使用して新しい] ob インスタンスを生成した後、その仕事をチャンネ 
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ルの送信側に送信しています。送信が失敗した時のために send に対して unwrap を呼び出していま 
す。これは例えば、全スレッドの実行を停止させるなど、受信側が新しいメッセージを受け取るのを 
やめてしまったときなどに起こる可能性があります。現時点では、スレッドの実行を止めることはで 
きません：スレッドは、プールが存在する限り実行し続けます。 unwrap を使用している理由は、失敗 
する場合が起こらないとわかっているからですが、 コンパイ ラにはわかりません。 

ですが、まだやり終えたわけではありませんよ！ワーカー内で thread : : spawn に渡されているク 
ロージャは、それでもチャンネルの受信側を参照しているだけです。その代わりに、クロージャには 
永遠にループし、チャンネルの受信側に仕事を要求し、仕事を得たらその仕事を実行してもらう必要 
があります。リスト 20-20 に示した変更を Worker : : new に行いましょう。 

ファイル名： src / lib.rs 
// __ snip -- 
impl Worker i . 

fn new ( id : usize , receiver : Arc く Mutex < mpsc : : ReceiverOob >>>) -> Worker { 
let thread = thread : : spawn (move || { 
loop { 

let job = receiver . lock () . unwrap (). recv () . unwrap (); 

// ワーカー {} は仕事を得ました；実行します 

pnntin ! ("Worker {} got a nob ; executing .”， id ); 

(* job )(); 

} 

})； 


Worker { 
id , 

thread , 



リスト 20-20: ワーカーのスレッドで仕事を受け取り、実行する 

ここで、まず receiver に対して lock を呼び出してミユーテックスを獲得し、それから unwrap を 
呼び出して、エラーの際にはパニックします。ロックの獲得は、ミューテックスが毒された状態なら 
失敗する可能性があり、これは、他のどれかのスレッドがロックを保持している間に、解放するので 
はなく、パニックした場合に起き得ます。この場面では、 unwrap を呼び出してこのスレッドをパニッ 
クさせるのは、取るべき正当な行動です。この unwrap をあなたにとって意味のあるエラーメッセー 
ジを伴う expect に変更することは、ご自由に行なってください。 

ミューテックスのロックを獲得できたら、 recv を呼び出してチャンネルから] ob を受け取ります。 
最後の unwrap もここであらゆるエラーを超えていき、これはチャンネルの送信側を保持するスレッ 
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ドが閉じた場合に発生する可能性があり、受信側が閉じた場合に send メソッドが Err を返すのと似 
ています。 

recv の呼び出しはブロックするので、まだ仕事がなければ、現在のスレッドは、仕事が利用可能に 
なるまで待機します。 Mutex<T> により、ただ1つの Worker スレッドのみが一度に仕事の要求を試み 
ることを保証します。 

理論的には、このコードはコンパイルできるはずです。残念ながら、 Rust コンパイラはまだ完全で 
はなく、このようなエラーが出ます： 

error[E 016 1] : cannot move a value of type std::ops::FnOnce() + 

std: : marker: : Send: the size of std : :ops: : FnOnce() + std :: marker :: Send cannot be 

statically determined 

( エラー： std : :ops:: FnOnce() + std :: marker:: Send の値をムーブできません： 
std : :ops : : FnOnce () + std : : marker: : Send のサイズを静的に決定できません） 

-- > src/lib.rs :63:17 

I 

63 | (*job)(); 

| A A A A A A 

問題が非常に謎めいているので、エラーも非常に謎めいています。 Box<T> に格納された FnOnce ク 
ロージャを呼び出すためには （]ob 型エ イリ アスがそう）、呼び出す際にクロージャが self の所有権 
を奪うので、クロージャは自身を Box<T> からムーブする必要があります。一般的に、 Rust は Box く T> 
から値をムーブすることを許可しません。 コンパイ ラには、 Box<T> の内側の値がどれほどの大きさな 
のか見当がつかないからです：第15章で Box<T> に格納して既知のサイズの値を得たい未知のサイズ 
の何かがあるために Box <T> を正確に使用したことを思い出してください。 

リスト 17-15 で見かけたように、記法 self: Box<Se1f> を使用するメソッドを書くことができ、こ 
れにより、メソッドは Box<T> に格納された Self 値の所有権を奪うことができます。それがまさしく 
ここで行いたいことですが、残念ながらコンパイラはさせてくれません：クロージャが呼び出された 
際に振る舞いを実装する Rust の一部は、 self: Box<Self> を使用して実装されていないのです。故 
に、コンパイラはまだこの場面において self: Box く Self> を使用してクロージャの所有権を奪い、ク 
ロージャを Box<T> からムーブできることを理解していないのです。 

Rust は、コンパイラが改善できる箇所ではまだ、発展途上にありますが、将来的にリスト 20-20 
のコードは、ただ単純にうまく動くはずです。まさしくあなたのような方がこれや他の問題を修正す 
るのに取り掛かっています！この本を完了したら、是非ともあなたにも参加していただきたいです。 

ですがとりあえず、手頃なトリックを使ってこの問題を回避しましょう。この場合、 self: Box<Self 
>で、 Box<T> の内部の値の所有権を奪うことができることを コンパイラに 明示的に教えてあげます; 
そして、一旦クロージャの所有権を得たら、呼び出せます。これには、シグニチャに self: Box<Self> 
を使用する call_box というメソッドのある新しいトレイト FnBox を定義すること、 FnOnce() を実装 
する任意の型に対して FnBox を定義すること、型エイリアスを新しいトレイトを使用するように変更 
すること、 Worker を caU_box メソッドを使用するように変更することが関連します。これらの変更 
は、リスト 20-21 に表示されています。 
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ファイル名： src / lib.rs 
trait FnBox { 

fn call_box (self : Box く Self 〉）； 

} 

■impl く F: FnOnce() > FnBox for F { 
fn call_box (self : Box く F>) { 

(*self)() 

} 

} 

type Job = Box<FnBox + Send + 'static 〉； 

// --snip-- 
impl Worker { 

fn new (id : usize ， receiver: Arc く Mutex<mpsc :: Recei ver<Job>>>) -> Worker { 
let thread = thread: : spawn (move || { 
loop { 

let job = recei ver.lock() .unwrap(). recv() .unwrap(); 
println! ("Worker {} got a job; executing. 11 ， id); 
job.call_box(); 

} 

})； 


Worker { 
id , 

thread , 



リスト 20-21: 新しいトレイト FnBox を追加して Box く FnOnce () >の現在の制限を回避する 

まず、 FnBox という新しいトレイトを作成します。このトレイトには ca 11_ box という1つのメソッ 
ドがあり、これは、 self : Box < Self > を取って self の所有権を奪い、 Box < T > から値をムーブする点 
を除いて、他の Fn * トレイトの call メソッドと類似しています。 

次に、 FnOnce () トレイトを実装する任意の型 F に対して FnBox トレイトを実装します。実質的にこ 
れは、あらゆる FnOnce () クロージャが call_box メソッドを使用できることを意味します。 call_box 
の実装は、 （* self )() を使用して Box < T > からクロージャをムーブし、クロージャを呼び出します。 

これで] ob 型エイリアスには、新しいトレイトの FnBox を実装する何かの Box である必要が出てき 
ました。これにより、クロージャを直接呼び出す代わりに ] ob 値を得た時に Worker の caU _ box を使 
えます 0 任意の FnOnce () クロージャに対して FnBox トレイトを実装することは、チャンネルに送信 
する実際の値は何も変えなくてもいいことを意味します。もうコンパイラは、我々が行おうとしてい 
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ることが平気なことであると認識できます。 

このトリックは非常にこそこそしていて複雑です。完璧に筋が通らなくても心配しないでください ; 
いつの日か、完全に不要になるでしょう。 

このトリックの実装で、スレッドプールは動く状態になります！ cargo run を実行し、リクエスト 
を行なってください： 


$ cargo run 

Compiling he llo v0.1.0 (file : ///proiects/heilo) 
warning: field is never used : 'workers' 

--> src/lib.rs:7:5 

I 

7 | workers : Vec く Worker 〉， 

j A 八 AA 八 A 八 AAA 八八八八八八八八八八 

I 

=note : #[warn(dead_code)] on by default 


warning: field is never used : 'id' 

--> src/lib•rs:61:5 

I 

61 | id: usize, 

| AAAAAAAAA 

I 

=note : #[warn(dead_code)] on by default 


warning : field is never used : ' thread ' 

--> src / lib • rs :62:5 

I 

62 | thread : thread : : JoinHandle <()>, 

| 八八八八八八八八八八八八八八八八八八八八八 A 八八 AA 八八八八 

I 

= note : #[ warn ( dead _ code )] on by default 


Finished 
Running 
Worker 0 got 
Worker 2 got 
Worker 1 got 
Worker 3 got 
Worker 0 got 
Worker 2 got 
Worker 1 got 
Worker 3 got 
Worker 0 got 
Worker 2 got 


dev [unoptimized + debuginfo] target(s) in 0.99 secs 
'target/debug/hello' 
a job; executing, 
a job; executing, 
a job; executing, 
a job; executing, 
a job; executing, 
a job; executing, 
a job; executing, 
a job; executing, 
a job; executing, 
a job; executing. 


成功！もう非同期に接続を実行するスレッドプールができました。絶対に 4 つ以上のスレッドが 
生成されないので、サーバが多くのリクエストを受け取っても、システムは過負荷にならないでしょ 
う。 /sleep にリクエストを行なっても、サーバは他のスレッドに実行させることで他のリクエストを 
提供できるでしょう。 
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第18章で while let ループを学んだ後で、なぜリスト 20-22 に示したようにワーカースレッドの 
コードを記述しなかったのか、不思議に思っている可能性があります。 


ファイル名： src / lib.rs 


// --snip 


imp l Worker { 

fn new ( id : usize ， receiver : Are < Mutex < mpsc :: Recei ver < Job >>>) -> Worker { 
let thread = thread : : spawn (move || { 

while let Ok ^ job ) = receiver . lock (). unwrap (). recv () { 
println! ("Worker {} got a job ; executing . n ， id ); 


})； 


job.call_box(); 


Worker { 
id , 

thread , 



リスト 20-22: while let を使用したもう 1 つの Worker: : new の実装 

このコードは コンパイル でき、動きますが、望み通りのスレッドの振る舞いにはなりません：遅い 
リクエストがそれでも、他のリクエストが処理されるのを待機させてしまうのです。理由はどこか捉 
えがたいものです： Mutex 構造体には公開の unlock メソッドがありません。ロックの所有権が、 lock 
メソッドが返す LockResult<MutexGuard<T>> 内の MutexGuard<T> のライフタイムに基づくからです。 
コンパイル 時には、ロックを保持していない限り、借用チェッカーはそうしたら、 Mutex に保護され 
るリソースにはアクセスできないという規則を強制できます。しかし、この実装は、 MutexGuard<T> 
のライフタイムについて熟考しなければ、意図したよりもロックが長い間保持される結果になり得ま 
す。 while 式の値がブロックの間中スコープに残り続けるので、ロックは job.caH_box の呼び出し 
中保持されたままになり、つまり、他のワーカーが仕事を受け取れなくなるのです。 

代わりに loop を使用し、ロックと仕事をブロックの外ではなく、内側で獲得することで、 lock メ 
ソッドが返す MutexGuard は let job 文が終わると同時にドロップされます。これにより、複数のリ 
クェ スト を並行で提供し、ロックは reev の呼び出しの間は保持されるけれども、 job.caU_box の呼 
び出しの前には解放されることを保証します。 


20.3 優美なシャットダウンと片付け 

リスト 20-21 のコードは、意図した通り、スレッドプールの使用を通してリクエストに非同期に応 
答できます。何も片付けを行なっていないと思い出せてくれる、直接使用していない workers 、 id 、 
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thread フィールドについて警告が出ます。優美さに欠ける Ctrl-C を使用してメインスレッドを停止 
させる方法を使用すると、リクエストの処理中であっても、他のスレッドも停止します。 

では、閉じる前に取り掛かっているリクエストを完了できるように、プールの各スレッドに対して 
join を呼び出す Drop トレイトを実装します。そして、スレッドに新しいリクエストの受付を停止し、 
終了するように教える方法を実装します。このコードが動いているのを確かめるために、サーバを変 
更して優美にスレッドプールを終了する前に2つしかリクエストを受け付けないようにします。 

20.3.1 ThreadPool に Drop トレイトを実装する 

スレッド プールに Drop を実装するところから始めましょう。プールが ドロップされ ると、 スレッ 
ドは全て join して、作業を完了するのを確かめるべきです。 リスト 20-23 は、 Drop 実装の最初の試 
みを表示しています；このコードはまだ完全には動きません。 

ファイル名： src / lib.rs 


impl Drop for I'hreadPool{ 
fn drop(&mut self) { 

for worker in &mut self .workers { 

// ワーカー {} を終了します 

println! ("Shutting down worker {}" , worker. id) ; 
worker.thread.join()•unwrap(); 

} 

} 

} 

リスト 20-23: スレッ ド プールがスコープを 抜けた時に スレッ ドを join させる 

まず、スレッドプール workers それぞれを走査します。 self は可変参照であり、 worker を可変化 
できる必要もあるので、これには &mut を使用しています。ワーカーそれぞれに対して、特定のワー 
カーを終了する旨のメッセージを出力し、それから join をワーカースレッドに対して呼び出してい 
ます。 join の呼び出しが失敗したら、 unwrap を使用して Rust をパニックさせ、優美でないシャット 
ダウンに移行します。 

こちらが、このコードをコンパイルする際に出るエラーです： 

error[E0507] : cannot move out of borrowed content 
--> src/lib.rs:65:13 

I 

65 | worker.thread.join().unwrapO; 

I aaaaaa cannot move out of borrowed content 


各 worker の可変参照しかなく、 join は引数の所有権を奪うためにこのエラーは join を呼び出せ 
ないと教えてくれています。この問題を解決するには、 join がスレッドを消費できるように 、 thread 
を所有する Worker インスタンスからスレッドをムーブする必要があります。これをリスト 17-15 で 
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は行いました： Worker が代わりに Opti on < thread :: 3 oi nHandle < ()>> を保持していれば、 Option に 
対して take メソッドを呼び出し、 Some 列挙子から値をムーブし、その場所に None 列挙子を残すこ 
とができます。言い換えれば、実行中の Worker には thread に Some 列挙子があり、 Worker を片付け 
たい時には、ワーカーが実行するスレッドがないように Some を None で置き換えるのです。 

従って、 Worker の定義を以下のように更新したいことがわかります： 

ファイル名： src / lib.rs 

# use std :: thread ; 
struct Worker { 
id : usize , 

thread : Opti on < th read :: 3 oinHandle < ()>>, 

} 

さて、コンパイラを頼りにして他に変更する必要がある箇所を探しましょう。このコードをチェッ 
クすると、2 つの エラーが出ます： 


error*[E0599] : no method named ]cnn found for tvpe 

'std::option::0ption<std: : thread: : JoinHandle<()>>' in the current scope 
--> src/lib.rs:65:27 

I 

65 | worker.thread.join().unwrap(); 

| AAA A 

error[E0308] : mismatched types 
--> src/lib.rs:89:13 

I 

89 | thread, 

| AAAAAA 

I I 

| expected enum 'std::option::Option', found struct 

'std: : thread :: 3oinHandle' 

| help : try using a variant of the expected type : 'Some(thread)' 

I 

=note : expected type 'std::option::0ption<std: : thread::3oinHandle<()>>' 
found type 'std :: thread :: 3oinHandle<_>' 

2 番目のエラーを扱いましょう。これは、 Worker :: new の最後のコードを指しています；新しい 
Worker を作成する際に、 Some に thread の値を包む必要があります。このエラーを修正するために以 
下の変更を行なってください： 

ファイル名： src / lib.rs 

impl Worker { 

rn new い d: usize, receiver: Arc<Mutex<mpsc :: Recen ver< Job >>>) -> Worker { 

// --snip -- 


Worker { 
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id , 

thread : Some ( thread ) , 



最初のエラーは Drop 実装内にあります。先ほど、 Option 値に対して take を呼び出し、 thread を 
worker からムーブする意図があることに触れました。以下の変更がそれを行います： 

ファイル名： src / lib.rs 


impl Drop for mreadPool { 
fn drop(&mut self ) { 

for worker in &mut self .workers { 

println! ("Shutting down worker {}" , worker . id ); 


if let Some ( thread ) = worker . thread . take () 
thread • join().unwrapO ; 


} 


第 17 章で議論したように、 Option の take メソッドは、 Some 列挙子を取り出し、その箇所に None 
を残します。 if let を使用して Some を分配し、スレッドを得ています；そして、スレッドに対して 
join を呼び出します。ワーカーのスレッドが既に None なら、ワーカーはスレッドを既に片付け済み 
であることがわかるので、その場合には何も起きません。 


20.3 .2 スレッドに仕事をリッスンするのを止めるよう通知する 

行なった変更と共に、コードは警告なしでコンパイルできます。ですが悪い知らせは、このコード 
が期待したようにはまだ機能しないことです。鍵は、 Worker インスタンスのスレッドで実行されるク 
ロージャのロジックです：現時点で join を呼び出していますが、仕事を求めて永遠に loop するので、 
スレッドを終了しません。現在の drop の実装で ThreadPool をドロップしようとしたら、最初のス 
レッドが完了するのを永遠に待機してメインスレッドはブロックされるでしょう。 

この問題を修正するには、スレッドが、実行すべき] ob か、リッスンをやめて無限ループを抜ける 
通知をリッスンするように、変更します。 ]ob インスタンスの代わりに、チャンネルはこれら 2 つの 
enum 列挙子の一方を送信します。 

ファイル名： src / lib.rs 

# struct Job : 
enum Message { 

New 3 ob ( Job ) ， 

Terminate , 
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} 

この Message enum はスレッドが実行すべき] ob を保持する New]ob 列挙子か、スレッドをループ 
から抜けさせ、停止させる Terminate 列挙子のどちらかになります。 

チャンネルを調整し、型] ob ではなく、型 Message を使用するようにする必要があります。リスト 
20-24 のようにですね。 

ファイル名： src / lib.rs 

pub struct ThreadPool{ 
workers : Vec く Worker〉, 
sender: mpsc: : Sender<Message> , 

} 

// -- snip -- 

impl ThreadPool { 

// -- snip __ 

pub fn execute<F> (&self , f: F) 
where 

F : FnOnceQ + Send + ’static 

{ 

let job = Box:: new ⑴； 

self . sender. send (Message: : NewJob^job)) . unwrapO ; 



// __ snip -- 
impl Worker { 

fn new ( id : usize , receiver : Arc く Mutex < mpsc : : Receiver < Message >>>) -> 
Worker { 

let thread = thread : : spawn (move ||{ 
loop { 

let message = receiver . lock() .unwrapO . recv () .unwrapO ; 

match message { 

Message : : NewJob ( job ) => { 

println! ("Worker {} got a job ; executing ."， id ) ; 

job . call _ box (); 

}, 

Message::Terminate => { 

// ワーカー {} は停止するよう指示された 

println ! ("Worker {} was told to terminate . 11 ， id ); 


break ; 
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})； 


Worker { 
id, 

thread : Some(thread ) ， 



リスト 20-24: Message 値を送受信し、 Worker ■が Message: :Ter*minate を受け取ったら、ループを 
抜ける 

Message eiUlITl を具体化するために、2箇所で；] ob を Message に変更する必要があります: 
ThreadPool の定義と Worker : : new のシグニチヤです。 ThreadPool の execute メソッドは、仕事 
を Message : : NewJob 列挙子に包んで送信する必要があります。それから、 Message がチヤンネルから 
受け取られる Worker* : : new で、 New]ob 列挙子が受け取られたら、仕事が処理され、 Terminate 列挙子 
が受け取られたら、スレッドはループを抜けます。 

これらの変更と共に、コードはコンパイルでき、リスト 20-21 の後と同じように機能し続けます。 
ですが、 Terminate のメッセージを何も生成していないので、警告が出るでしょう。 Drop 実装をリス 
卜 20-25 のような見た目に変更してこの警告を修正しましょう。 

ファイル名： src / lib.rs 


imp l Drop tor ThreadPool{ 
fn drop(&mut self) { 

println! ("Sending terminate message to all workers. ; 


for _ in &mut self .workers { 

self .sender. send (Message : :Terminate).unwrap(); 

} 

// 全ワーカーを閉じます 

println! ("Shutting down all workers. ") ; 

for worker in &mut self .workers { 

// ワーカー {} を閉じます 

println! ("Shutting down worker {}" , worker. id) ; 

if let Some(thread) = worker.thread.take() { 
thread. join() .unwrapO ; 


} 


} 


} 


} 
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リスト 20-25: 各ワーカースレッドに対して join を呼び出す前にワーカーに Message : : Termi nate 
を送信する 

今では、ワーカーを2回走査しています：各ワーカーに Terminate メッセージを送信するために1 
回と、各ワーカースレッドに join を呼び出すために1回です。メッセージ送信と join を同じループ 
で即座に行おうとすると、現在の繰り返しのワーカーがチャンネルからメッセージを受け取っている 
ものであるか保証できなくなってしまいます。 

2つの個別のループが必要な理由をよりよく理解するために、2つのワーカーがある筋書きを想像 
してください。単独のループで各ワーカーを走査すると、最初の繰り返しでチャンネルに停止メッ 
セージが送信され、 join が最初のワーカースレッドで呼び出されます。その最初のワーカーが現在、 
リクエストの処理で忙しければ、2番目のワーカーがチャンネルから停止メッセージを受け取り、閉 
じます。最初のワーカーの終了待ちをしたままですが、2番目のスレッドが停止メッセージを拾って 
しまったので、終了することは絶対にありません。デッドロックです！ 

この筋書きを回避するために、1つのループでまず、チャンネルに対して全ての Termi nate メッ 
セージを配置します；そして、別のループで全スレッドの join を待ちます。一旦停止メッセージを受 
け取ったら、各ワーカーはチャンネルでリクエストの受付をやめます。故に、存在するワーカーと同 
じ数だけ停止メッセージを送れば、 join がスレッドに対して呼び出される前に、停止メッセージを各 
ワーカーが受け取ると確信できるわけです。 

このコードが動いているところを確認するために、 main を変更してサーバを優美に閉じる前に2つ 
しかリクエストを受け付けないようにしましょう。リスト 20-26 のようにですね。 

ファイル名： src / bin / main.rs 
fn mann () { 

let listener = TcpListener : : bind ("127. 0.0.1:7878") . unwrap (); 

let pool = ThreadPool : : new (4); 

for stream in listener . incomingO . take (2) { 
let stream = stream.unwrapO ; 

pool . execute (|| { 

handle _ connection ( stream ); 

})； 

} 

println ! ("Shutting down . 11 ); 

} 

リスト 20-26: ループを抜けることで、2 つの リク エス トを処理した後にサーバを閉じる 

現実世界の Web サーバには、たった2つしかリクエストを受け付けた後に閉じてほしくはないで 
しょう。このコードは、単に優美なシャットダウンと片付けが機能する状態にあることを模擬するだ 
けです。 
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take メソッドは、 Iterator* トレイトで定義されていて、最大でも繰り返しを最初の 2 つの要素だ 
けに制限します。 ThreadPool は main の末端でスコープを抜け、 drop 実装が実行されます。 

cargo run でサーバを開始し、3つリクエストを行なってください。3番目のリクエストはエラー 
になるはずで、端末にはこのような出力が目撃できるはずです： 


$ cargo run 

Compiling heLLo v0.1.0 (file : ///proiects/heLlo) 

Finished dev [unoptimized + debuginfo] target(s) in 1.0 secs 
Running 'target/debug/hello' 

Worker 0 got a job; executing. 

Worker 3 got a job; executing. 

Shutting down. 

Sending terminate message to ail workers. 

Shutting down all workers. 

Shutting down worker 0 
Worker 1 was told to terminate. 


Worker 2 was told to terminate. 
Worker 0 was told to terminate. 
Worker 3 was told to terminate. 


Shutting down worker 1 
Shutting down worker 2 
Shutting down worker 3 


ワーカーとメッセージの順番は異なる可能性があります。どうやってこのコードが動くのかメッ 
セージからわかります：ワーカー0と3が最初の2つのリクエストを受け付け、そして3番目のリク 
エストではサーバは接続の受け入れをやめます。 main の最後で ThreadPool がスコープを抜ける際、 
Drop 実装が割り込み、プールが全ワーカーに停止するよう指示します。ワーカーはそれぞれ、停止 
メッセージを確認した時にメッセージを出力し、それからスレッドプールは各ワーカースレッドを閉 
じる join を呼び出します。 

この特定の実行のある面白い側面に気付いてください： ThreadPool はチャンネルに停止メッセージ 
を送信し、あらゆるワーカーがそのメッセージを受け取る前に、ワーカー0の join を試みています。 
ワーカー0はまだ停止メッセージを受け取っていなかったので、メインスレッドはワーカー0が完了 
するまで待機してブロックされます。その間に、各ワーカーは停止メッセージを受け取ります。ワー 
カー0が完了したら、メインスレッドは残りのワーカーが完了するのを待機します。その時点で全 
ワーカーは停止メッセージを受け取った後で、閉じることができたのです。 

おめでとうございます！プロジェクトを完成させました； スレッ ドプールを使用して非同期に応答 
する基本的な' Web サーバができました。サーバの優美な シャッ トダウンを行うことができ、プール 
の全 スレッ ドを片付けます。 

こちらが、参考になる全コードです： 


フアイル名： src / bm / mam.rs 

extern crate hel lo; 
use hello::ThreadPool; 
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use std : : io : : prelude : 

use std :: net : : TcpListener ; 

use std : : net : : TcpStream ; 

use std :: ts: : File ; 

use std :: thread ; 

use std :: time: : Durati on ; 

fn mai . n () { 

let listener = TcpListener: : bind ("127. 0.0. 1:7878") . unwrap (); 
let pool = ThreadPool : : new (4); 

for stream in listener . incomingO . take (2) { 
let stream = stream.unwrapO ; 

pool . execute (|| { 

handle _ connection ( stream ); 

})； 


// 閉じます 

println! ("Shutting down ."); 


fn handle_connection (mut stream: FcpStream) { 
let mut buffer = [0; 512]; 
stream, read (&mut buffer).unwrapO ; 

let get = b"GET / HTTP/1.l\r\n" ; 

let sleep = b"GET /sleep HTTP/1.l\r\n" ; 

let (status_line, filename) = if buffer.starts_with(get) { 
("HTTP/1.1200 0K\r\n\r\n M , "hello.html") 

} else if buffer.starts_with(sleep) { 

thread :: sleep (Durati on :: from_secs(5)); 

("HTTP/1.1200 0K\r\n\r\n" , "hello.html") 

} else { 

("HTTP/1.1404 NOT F0UND\r\n\r\n" , "404. html") 

}； 


let mut file = Fi Le : : open ( filename ) .unwrapO ; 
let mut contents = Stri ng : : new (); 


file . read _ to _ stri ng(&mut contents ) .unwrapO ; 


let response = format ! ("{}{}" , status _ line , contents ); 

st ream , write ( response . as _ bytes ()). unwrapO ; 
stream . flush () .unwrapO ; 


フアイル名： src / lib.rs 
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use std :: thread ; 
use std :: svnc :: mpsc ; 
use std :: svnc :: Arc ; 
use std :: svnc :: Mutex ; 

enum Message { 

New 3 ob ( Job ), 

Terrm nate , 

} 

pub struct ThreadPool { 
workers : Vec < Worker >, 
sender : mpsc : : Sender < Message > , 

} 


trait FnBox { 

fn call_box (self : Box く Self 〉）； 

} 

impl く F: FnOnce ()> FnBox for F { 
fn call 一 box (self : Box く F>) { 
(*self)() 

} 

} 

type Job = Box<FnBox + Send + ' stati c> ; 


impl ThreadPool{ 

III Create a new ThreadPool. 

Ill 

III The size is the number of threads in the pool. 

Ill 

III # Panics 

III 

III The 'new' function will panic if the size is zero. 
pub fn new(size: usize) -> ThreadPool{ 
assert! (size > 0); 

let (sender, receiver) = mpsc :: channel(); 
let receiver = Arc: :new (Mutex: : new(receiver)); 
let mut workers = Vec: : with_capacity (size) ; 
for id in 0.. size { 

workers . push(Worker :: new い d ， Arc :: clone(&receiver))); 

} 


ThreadPool{ 
workers, 
sender, 

} 
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} 


pub fn execute < F >(& se Lf ， f : F ) 
where 

F : FnOnce () + Send + ’static 

{ 

let job = Box :: new ( f ); 


self . sender . send ( Message : : New 3 ob ( job )). unwrapO ; 


} 


impl Drop for ThreadPool { 
fn drop(&mut self) { 

println! ("Sending terminate message to all workers. ; 

for _ in &mut self .workers { 

self .sender. send (Message :: Terminate).unwrapO; 

} 

println! ("Shutting down all workers. 11 ); 

for worker in &mut self .workers { 

println! ("Shutting down worker {}" , worker.id) ; 

if let Some(thread) = worker.thread.take() { 
thread• join().unwrapO ; 

} 


} 

struct Worker { 
id : usize , 

thread : Option < thr * ead : : 3 oinHandle < () >> , 

} 

impl Worker { 

fn new ( id : usize , receiver : Arc < Mutex < mpsc :: Recei ver < Message >>>)-> 
Worker { 

let thread = thread :: spawn (move ||{ 
loop { 

let message = receiver . lock() .unwrapO . recv() .unwrapO ; 

match message { 

Message :: NewJob ( job ) => { 

println! ("Worker {} got a job ; executing . "， id ); 


job . call _ box (); 

}, 

Message::Terminate => { 

println ! ("Worker {} was told to terminate . 11 ， id ); 
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break ; 

}, 

} 

} 

})； 

Worker { 
id , 

thread : Some ( thread ), 



ここでできることはまだあるでしょう！よりこのプロジェクトを改善したいのなら、こちらがアイ 
ディアの一部です： 

• ThreadPool とその公開メソッドにもっとドキュメンテーションを追加する。 

• ライブラリの機能のテストを追加する。 

• unwrap の呼び出しをもっと頑健なエラー処理に変更する。 

• ThreadPool を使用して' Web リクエスト以外のなんらかの作業を行う。 

• https://crates.io でスレッドプールのクレートを探して、そのクレートを代わりに使用して 
似た' Web サーバを実装する。そして、 API と頑健性を我々が実装したものと比較する。 


20.4 まとめ 

よくやりました！本の最後に到達しました！ Rust のツアーに参加していただき、感謝の辞を述べ 
たいです。もう、ご自身の Rust プロジエクトや他の方のプロジエクトのお手伝いをする準備ができ 
ています。あなたの Rust の旅で遭遇するあらゆる挑戦の手助けを是非とも行いたい他の Rustacean 
の歓迎されるコミュニティがあることを心に留めておいてくださいね。 
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付録 


以下の節は、 Rust の旅で役に立つと思えるかもしれない参考資料を含んでいます。 

付録 A : キーワード 

以下のリストは、現在、あるいは将来 Rust 言語により使用されるために予約されているキーワー 
ドを含んでいます。そのため、識別子として使用することはできません。識別子の例は、関数名、変 
数名、引数名、構造体のフィールド名、モジュール名、クレート名、定数名、マクロ名、静的な値の 
名前、属性名、型名、トレイト名、ライフタイム名です。 

現在使用されているキーワード 

以下のキーワードは、解説された通りの機能が現状あります。 

• as - 基礎的なキャストの実行、要素を含む特定のトレイトの明確化、 use や extern crate 文の 
要素名を変更する 

• break - 即座にループを抜ける 

• const - 定数要素か定数の生ポインタを定義する 

• continue - 次のループの繰り返しに継続する 

• crate - 外部のクレートかマクロが定義されているクレートを表すマクロ変数をリンクする 

• else -if と if let フロー制御構文の規定 

• enum - 列挙型を定義する 

• extern - 外部のクレート、関数、変数をリンクする 

• false - bool 型の false リテラル 

• fn - 関数か関数ボインタ型を定義する 

• for - イテレータの要素を繰り返す、トレイトの実装、高階ライフタイムの指定 
• if - 条件式の結果によって条件分岐 

• impl - 固有の機能やトレイトの機能を実装する 

• in-for ループ記法の一部 
• let - 変数を束縛する 
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• loop -無条件にループする 

• match - 値をパターンとマッチさせる 

• mod - モジュ^ールを定義する 

• move -クロージャにキャブチャした変数全ての所有権を奪わせる 

• mut - 参照、生ポインタ、パターン束縛で可変性に言及する 

• pub - 構造体フィールド、 ■impl ブロック、モジュールで公開性について言及する 

• ref - 参照で束縛する 

• return -関数から帰る 

• Self -トレイトを実装する型の型エイリアス 

• self - メソッドの主題、または現在のモジュール 

• static - グローバル変数、またはプログラム全体に渡るライフタイム 

• struct - 構造体を定義する 

• super - 現在のモジュールの親モジュール 

• trait - トレイトを定義する 

• true - bool 型の true リテラル 

• type - 型エイリアスか関連型を定義する 

• unsafe - unsafe なコード、関数、トレイト、実装に言及する 

• use - スコ^ープにシンボルをインポ^ートする 

• where - 型を制限する節に言及する 

• while - 式の結果に基づいて条件的にループする 

将来的な使用のために予約されているキーワード 

以下のキーワードには機能が何もないものの、将来的に使用される可能性があるので、 Rust により 
予約されています。 


• abstract 

• alignof 

• become 

• box 
•do 

• final 

• macro 

• offsetof 

• override 

• priv 


proc 
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• pure 

• sizeoT 

• typeoT 

• unsized 

• virtual 

• yield 

付録 B : 演算子と記号 

この付録は、演算子や、単独で現れたり、パス、ジヱネリクス、トレイト境界、マクロ、属性、コ 
メント、タプル、かっこの文脈で現れる他の記号を含む Rust の記法の用語集を含んでいます。 

演算子 

表 B -1 は、 Rust の演算子、演算子が文脈で現れる例、短い説明、その演算子がオーバーロード可 
能かどうかを含んでいます。演算子がオーバーロー ド可能ならば、オーバーロードするのに使用する 
関係のあるトレイトも列挙されています。 

表 B -1: 演算子 


演算子 例 


オーバーロー ドで 

説明 きる？ 


1 

ident !(...) , ident 

ident![...] 

マクロ展開 


1 

! expr 

ビット反転、または論理反転 

Not 

1 = 

var ! = expr* 

非等価比較 

PartialEq 

% 

expr % expr 

余り演算 

Rem 

% 二 

var 96 = expr 

余り演算後に代入 

RemAssign 

& 

&expr , &mut expr 

借用 


& 

&type , &mut type ，& , a type , 

&' a mut type 

借用されたポインタ型 


& 

expr & expr 

ビット AND 

BitAnd 

&= 

var &= expr 

ビット AND 後に代入 

BitAndAssign 

&& 

expr && expr 

論理 AND 


•k 

expr ^ expr 

掛け算 

Mul 

■k 

★ expr 

参照外し 


•k 

‘const type , ‘mut type 

生ポインタ 
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演算子 

例 

説明 

オーバーロー ドで 

きる？ 

•k = 

var *= expr 

掛け算後に代入 

MulAssign 

+ 

trait + trait, 'a + trait 

型制限の複合化 


+ 

expr + expr 

足し算 

Add 

十二 

var += expr 

足し算後に代入 

AddAssign 

> 

expr, expr 

引数と要素の区別 


- 

- expr 

算術否定 

Neg 

- 

expr - expr 

引き算 

Sub 

-= 

var -= expr 

引き算後に代入 

SubAss]gn 

-> 

fn(•••) -> type , 

関数とクロージャの戻り値型 



| … 丨 -> type 




expr* • ident 

メンバーアクセス 



..,expr*• . , . .expr * ， 

未満範囲リテラル 



expr..expr 




• • expr 

構造体リテラル更新記法 



van' ant (x ， ..), 

「残り全部」パターン束縛 



str*uct_type { x, . . } 




expr...expr 

パターンで：以下範囲パ 




ターン 


/ 

expr / expr 

割り算 

Div 

/ = 

var /= expr* 

割り算後に代入 

DivAssign 


pat : type,ident: type 

型制約 



ident: expr 

構造体フイールド初期化子 



'a : loop {...} 

ループラベル 


j 

expr; 

文、要素終端子 


} 

[...;len] 

固定長配列記法の一部 


<< 

expr << expr 

左シフト 

Shi 

<< = 

var <<= expr 

左シフト後に代入 

ShlAssign 

< 

expr < expr 

未満比較 

PartialOrd 

< = 

expr <= expr 

以下比較 

PartialOrd 

= 

var = expr,ident = type 

代入/等価 


== 

expr == expr 

等価比較 

PartialEq 

=> 

pat => expr 

match アーム記法の一部 


> 

expr > expr 

より大きい比較 

PartialOrd 

> = 

expr >= expr 

以上比較 

PartialOrd 
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演算子 

例 

説明 

オーバーロー ドで 

きる？ 

>> 

expr >> expr 

右 シフト 

Shr 

>>= 

var >>= expr 

右 シフト 後に代入 

ShrAssign 

@ 

ident @ pat 

パターン束縛 


A 

expr A expr 

ビット XOR 

BitXor 

A 二 

var A = expr 

ビット XOR 後に代人 

BitXorAssign 

1 

pat | pat 

パターン OR 


1 

| ••- 1 expr 

クロージャ 


1 

expr | expr 

ビット OR 

BitOr 

= 

var |= expr 

ビット OR 後に代入 

BitOrAssign 

II 

expr 丨丨 expr 

論理 OR 


? 

expr? 

エラー 委譲 



演算子以外のシンボル 

以下のリストは、演算子として機能しない記号全部を含んでいます；つまり、関数やメソッド呼び 
出しのようには、振る舞わないということです。 

表 B-2 は、単独で出現し、いろんな箇所で合法になる記号を示しています。 

表 B-2: スタンドアロー ン記法 

シンボル 説明 

’ident 名前付きのライフタイム、あるいはループラベル 

...u8, ...i32, . . . f 64 特定の型の数値リテラル 

, ...usize なと 

文字列リテラル 

生文字列リテラル、エスケープ文字は処理されません 

「##"•• . "## など 

b"..." バイト文字列リテラル、文字列の代わりに [u8 ] を構築します 

br"...",br#"..."#, 生バイト文字列リテラル、生文字列とバイト文字列の組み合わせ 

br##". . ."## など 

文字リテラル 

b'...' ASCII パイトリテラル 

| . . . | expr クロージャ 

! 常に発散関数の空のボトム型 
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シンボル 

説明 

- 

「無視」パターン束縛：整数リテラルを見やすくするのにも使われる 

表 B -3 は、要素へのモジ 

表 B -3: パス関連記法 

ュール階層を通したパスの文脈で出現する記号を示しています。 

シンボル 

説明 

ident : : ident 

:: path 

self :: path 

super :: path 

type :: ident , <type as 

trait> : :ident 

名前空間パス 

クレートルートに相対的なパス（すなわち、明示的な絶対パス） 

現在のモジュールに相対的なパス（すなわち、明示的な相対パス） 

現在のモジュールの親モジュールに相対的なパス 

関連定数、関数、型 

< type >. 

trait : : method (...) 

type :: method (...) 

<type as trait > :: 

method (...) 

直接名前付けできない型の関連要素（例，, <[ T ]> :: ...など） 

定義したトレイトを名指ししてメソッド呼び出しを明確化する 

定義されている型を名指ししてメソッド呼び出しを明確化する 

トレイトと型を名指ししてメソッド呼び出しを明確化する 

表 B -4 は、ジェネリックな型引数の文脈で出現する記号を示しています。 

表 B -4: ジェネリクス 

シンボル 

説明 


path く ... > 
path , 
method 

fn ident <...> ... 
struct ident <...> 


型の内部のジェネリック型への引数を指定する（例、 Vec < u 8> ) 

式中のジヱネリックな型、関数、メソッドへの引数を指定する。しばし 
ばターボ.フィッシュ ( turbofish ) と称される。（例、 

"42". parse :: < i 32>()) 

ジェネリックな関数を定義する 
ジェネリックな構造体を定義する 


enum ident < •••>... ジヱネリックな列挙型を定義する 

... ジヱネリックな実装を定義する 
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シンボル 

説明 


for <...> type 高階ライフタイム境界 

type く ident = type > 1つ以上の関連型に代入されたジヱネリックな型 （例、 

Iterator < Item = T > ) 


表 B -5 は、ジヱネリック型引数をトレイト境界で制約する文脈で出現する記号を示しています。 
表 B -5: トレイト境界制約 


シンボル 説明 


T ： U 

T : 'a 

U を実装する型に制約されるジェネリック引数 T 

ライフタイムのよりも長生きしなければならないジヱネリック型 T (型 

がライフタイムより長生きするとは、 'a よりも短いライフタイムの参 

照を何も遷移的に含められないことを意味する） 

T : 'static 

ジェネリック型 T が ' static なもの以外の借用された参照を何も含ま 


ない 

' b : 'a 

ジェネリックなライフタイム ’b がライフタイム 'a より長生きしなけれ 

ばならない 

T : ?Si zed 

ジェネリック型引数が動的サイズ付け型であることを許容する 

'a + trait , 

複合型制約 

trait + trait 



表 B -6 は、マクロの呼び出しや定義、要素に属性を指定する文脈で出現する記号を示しています。 
表 B -6: マクロと属性 


シンボル 説明 


# [ meta ] 

外部属性 

#! [ meta ] 

内部属性 

$ident 

マクロ代用 

$ ident:kind 

マクロキヤプチヤ 

$ (…）… 

マクロの繰り返し 


表 B -7 は、コメントを生成する記号を示しています。 
表 B -7: コメント 
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シンボル 

説明 


// 

行コメント 

II '. 

内部行 doc コメント 

Ill 

外咅 P 行 doc コメント 

， ★•• •女， 

ブロックコメント 

/★!•••★/ 

内部ブロック doc コメン 


外部ブロック doc コメン 


タプル 

表 B -8 は、タプルの文脈で出現する記号を示しています。 

表 B -8: タプル 


シンボル 

説明 


0 

空のタプル（ュニットとしても知られる)、 

リテラル、型両方 

( expr ) 

括弧付きの式 


( expr ，） 

1要素タプル式 


( type ,) 

1要素タプル型 


( expr , …） 

タプル式 


( type , •••) 

タプル型 


expr(expr ， ...) 

関数呼び出し式；タプル struct やタプル 

も使用される 

enum 列挙子を初期化するのに 

ident !(•••)， 

マクロ呼び出し 


ident ! 

ident ![.. . ] 

expr . 0 , expr .1 , など 

タプル添え字アクセス 


表 B -9 は、波括弧が使用される文脈を表示しています。 


表 B -9: 波括弧 

文脈 

説明 


{•••} 

ブロック式 


Type {. ..} 

struct リアフル 
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表 B -10 は、角括弧が使用される文脈を表示しています。 

表 B -10: 角括弧 

文脈 

説明 

[…] 

Lexor ; len ] 

[ tvpe ; len ] 

expr [ expr 」 

expr [..] , expr [ a ..], 

expr [.. b ], expr [ a .. b ] 

配列リテラル 

len 個 expr を含む配列リテラル 

len 個の type のインスタンスを含む配列型 

コレクション添え字アクセス。オーバーロード可能 (index , IndexMut ) 
Range 、 RangeFrom 、 RangeTo 、 RangeFull を「添え字」として使用して 
コレクション • スライシングの振りをするコレクション添え字アクセス 


付録 C : 継承可能なトレイト 

本のいろんな箇所で derive 属性について議論しました。これは構造体や、 enum 定義に適用でき 
ます。 derive 属性は、 de 门 — ve 記法で注釈した型に対して独自の規定の実装でトレイトを実装するコー 
ドを生成します。 

この付録では、標準ライブラリの derive と共に使用できる全トレイトの参照を提供します。各節 
は以下を講義します： 

• このトレイトを継承する演算子やメソッドで可能になること 
• derive が提供するトレイトの実装がすること 
• トレイトを実装することが型についてどれほど重要か 
• そのトレイトを実装できたりできなかったりする条件 
• そのトレイトが必要になる処理の例 


derive 属性が提供する以外の異なる振る舞いが欲しいなら、それらを手動で実装する方法の詳細に 
ついて、各トレイトの標準ライブラリのドキュメンテーションを調べてください。 

標準ライブラリで定義され ている 残りのトレイトは、 derive で自分の型に実装することはできませ 
ん。これらのトレイトには知覚できるほどの規定の振る舞いはないので、自分が達成しようしている 
ことに対して、道理が通る方法でそれらを実装するのはあなた次第です。 

継承できないトレイトの例は Display で、これはエンドユーザ向けのフォーマットを扱います。常 
に、エンドユーザ向けに型を表示する適切な方法について、考慮すべきです。型のどの部分をエンド 
ユーザは見ることができるべきでしょうか？どの部分を関係があると考えるでしょうか？どんな形 
式のデータがエンドユーザにとって最も関係があるでしょうか？ Rust コンパイラには、この見識が 
ないため、適切な規定動作を提供してくれないのです。 
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この付録で提供される継承可能なトレイトのリストは、包括的ではありません：ライブラリは、自 
身のトレイトに derive を実装でき、 derive と共に使用できるトレイトのリストが実に限りのないも 
のになってしまうのです。 derive の実装には、プロシージャルなマクロが関連します。マクロについ 
ては、付録 D で講義します。 


プログラマ用の出力の Debug 

Debug トレイトにより、 フォーマッ ト文字列でのデバッグ整形が可能になり、 {} プレースホルダー 
内に：？を追記することで表します。 

Debug トレイトにより、デバッグ目的で型のインスタンスを出力できるようになるので、あなたや 
型を使用する他のプログラマが、プログラムの実行の特定の箇所でインスタンスを調べられます。 

Debug トレイトは、例えば、 assert_eq !マクロを使用する際などに必要になります。このマクロ 
は、プログラマがどうして2つのインスタンスが等価でなかったのか確認できるように、等価アサー 
卜が失敗したら、引数として与えられたインスタンスの値を出力します。 

等価比較のための PartlalEq と Eq 

PartialEq トレイトにより、型のインスタンスを比較して、等価性をチヱックでき、==とい演算子 
の使用を可能にします。 

PartialEq を継承すると、 eq メソッドを実装します。構造体に PartialEq を継承すると、全フィー 
ル ドが等しい時のみ2つのイ ンスタンスは 等価になり、いずれかのフィー ル ドが等価でなければ、イ 
ンスタンスは 等価ではなくなります。 enum に継承すると、各列挙子は、自身には等価ですが、他の 
列挙子には等価ではありません。 

PartialEq トレイトは例えば、 assert_eq !マクロを使用する際に必要になります。これは、等価性 
のためにとある型の2つのインスタンスを比較できる必要があります。 

Eq トレイトにはメソッドはありません。その目的は、注釈された型の全値に対して、値が自身と等 
しいことを通知することです。 Eq トレイトは、 PartialEq を実装する全ての型が Eq を実装できるわ 
けではないものの、 PartialEq も実装する型に対してのみ適用できます。これの一例は、浮動小数点 
数型です：浮動小数点数の実装により、非数字 (NaN) 値の2つのイ ンスタンス はお互いに等価ではな 
いことが宣言されます。 

Eq が必要になる一例が、 HashMap<K, V> のキーで、 HashMap<K, V> が、2つのキーが同じであると 
判定できます。 

順序付き比較のための PartlalOrd と Ord 

PartialOrd トレイトにより、ソートする目的で型のインスタンスを比較できます。 PartialOrd を 
実装する型は、<、>、<=、>=演算子を使用することができます。 PartialEq も実装する型に対して 
のみ、 PartialOrd トレイトを適用できます。 
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PartialOrd を継承すると、 partial__cmp メソッドを実装し、これは、与えられた値が順序付けられ 
ない時に None になる Opti on<Orderi ng> を返します。その型のほとんどの値は比較できるものの、順 
序付けできない値の例として、非数字 （ NaN) 浮動小数点値が挙げられます。 partial._cmp をあらゆる 
浮動小数点数と NaN 浮動小数点数で呼び出すと、 None が返るでしょう。 

構造体に継承すると、フィールドが構造体定義で現れる順番で各フィールドの値を比較することで 
2つのインスタンスを比較します。 enum に継承すると、 enum 定義で先に定義された列挙子が、後 
に列挙された列挙子よりも小さいと考えられます。 

PartialOrd トレイトが必要になる例には、低い値と高い値で指定される範囲の乱数を生成する 
rand クレートの gen_range メソッドが挙げられます。 

Ord トレイトにより、注釈した型のあらゆる2つの値に対して、合法な順序付けが行えることが 
わかります。 Ord トレイトは cmp メソッドを実装し、これは、常に合法な順序付けが可能なので、 
Option<Orderi ng> ではなく、 Orderi ng を返します。 PartialOrd と Eq (Eq は Partial_Eq も必要とし 
ます）も実装している型にしか、 ord トレイトを適用することはできません。構造体と enum で継承 
したら、 PartialOrd で、 parti al__cmp の継承した実装と同じように cmp は振る舞います。 

Ord が必要になる例は、 BTreeSet<T> に値を格納する時です。これは、値のソート順に基づいてデー 
夕を格納するデータ構造です。 

値を複製する Clone と Copy 

Clone トレイトにより値のディープコピーを明示的に行うことができ、複製のプロセスは、任意の 
コードを実行し、ヒープデータをコピーすることに関係がある可能性があります。 Clone について 詳 
しくは、第4章の「変数とデータの相互作用法： Clone 」 節を参照されたし。 

Clone を継承すると、 clone メソッドを実装し、これは型全体に対して実装されると、型の各部品に 
対して clone を呼び出します。要するに、 Clone を継承するには、型のフィールドと値全部も Clone 
を実装していなければならないということです。 

Clone が必要になる例は、スライスに対して to_vec メソッドを呼び出すことです。スライスは、含 
んでいる型のインスタンスの所有権を持たないが、 to_vec で返されるベクタはそのインスタンスを所 
有する必要があるので、 to_vec は各要素に対して clone を呼び出します。故に、スライスに格納され 
る型は、 Clone を実装しなければならないのです。 

Copy トレイトにより、スタックに格納されたビットをコピーするだけで値を複製できます；任意の 
コードは必要ありません。 copy について詳しくは、第4章の「スタックのみのデータ： Copy 」 を参 
照されたし。 

Copy トレイトは、プログラマがメソッドをオーバーロードし、任意のコードが実行されないという 
前提を侵害することを妨げるメソッドは何も定義しません。そのため、全プログラマは、値のコピー 
は非常に高速であることを前提にすることができます。 

部品すべてが Copy を実装する任意の型に対して Copy を継承することができます。 Clone も実装す 
る型に対してのみ、 Copy トレイトを適用することができます。何故なら、 Copy を実装する型には、 
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Copy と同じ作業を行う Clone の瑣末（さまつ）な実装があるからです。 

Copy トレイトは稀にしか必要になりません； Copy を実装する型では最適化が利用可能になります。 
つまり、 clone を呼び出す必要がなくなり、コードがより簡潔になるということです。 

Copy で可能なこと全てが Clone でも達成可能ですが、コードがより遅い可能性や、 clone を使用し 
なければならない箇所があったりします。 

値を固定サイズの値にマップする Hash 

Hash トレイトにより、任意のサイズの型のインスタンスを取り、そのインスタンスをハッシュ関数 
で固定サイズの値にマップできます。 Hash を継承すると、 hash メソッドを実装します。 hash の継承 
された実装は、型の各部品に対して呼び出した hash の結果を組み合わせます。つまり、 Hash を継承 
するには、全フィールドと値も H ash を実装しなければならないということです。 

Hash が必要になる例は、 HashMap<K, V> にキーを格納し、データを効率的に格納することです。 

既定値のための Default 

Default トレイトにより、型に対して既定値を生成できます。 Default を継承すると、 default 関 
数を実装します。 default 関数の継承された実装は、型の各部品に対して default 関数を呼び出しま 
す。つまり、 Default を継承するには、型の全フィールドと値も Default を実装しなければならない 
ということです。 

Default: : default 関数は、第5章の「構造体更新記法で他のインスタンスからインスタンスを生 
成する」節で議論した構造体更新記法と組み合わせてよく使用されます。構造体のいくつかのフィー 
ルドをカスタマイズし、それから .. Default: :default() を使用して、残りのフィールドに対して既 
定値をセットし使用することができます。 

例えば、 Default トレイトは、 Option<T> インスタンスに対してメソッド unwrap_or_defau1t を使 
用する時に必要になります。 Option<T> が None ならば、メソッド unwrap_or_defaul_t は、 Option く T> 
に格納された型 T に対して Default: : default の結果を返します。 

付録 D : マクロ 

本全体で println! のようなマクロを使用してきましたが、マクロがなんなのかや、どう動いてい 
るのかということは完全には探究していません。この付録は、マクロを以下のように説明します： 

• マクロとはなんなのかと関数とどう違うのか 

• 宣言的なマクロを定義してメタプログラミングをする方法 

• プロシージャルなマクロを定義して独自の derive トレイトを生成する方法 


マクロは今でも、 Rust においては発展中なので、付録でマクロの詳細を講義します。マクロは変 
わってきましたし、近い将来、 Rustl . O からの言語の他の機能や標準ライブラリに比べて速いスピー 
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ドで変化するので、この節は、本の残りの部分よりも時代遅れになる可能性が高いです。 Rust の安定 
性保証により、ここで示したコードは、将来のバージョンでも動き続けますが、この本の出版時点で 
は利用可能ではないマクロを書くための追加の能力や、より簡単な方法があるかもしれません。この 
付録から何かを実装しようとする場合には、そのことを肝に銘じておいてください。 

マクロと関数の違い 

基本的に、マクロは、他のコードを記述するコードを書く術であり、これはメタプログラミングと 
して知られています。付録 C で、 derive 属性を議論し、これは、色々なトレイトの実装を生成してく 
れるのでした。また、本を通して println ! や vec ! マクロを使用してきました。これらのマクロは全 
て、展開され、手で書いたよりも多くのコードを生成します。 

メタプログラミングは、書いて管理しなければならないコード量を減らすのに有用で、これは、関 
数の役目の一つでもあります。ですが、マクロには関数にはない追加の力があります。 

関数 シグ ニチャは、関数の引数の数と型を宣言しなければなりません。一方、マクロは可変長の引 
数を取れます： println ! (" hello ") のように 1 引数で呼んだり、 pri ntln ! ("hello {}’’， name ) のよ 
うに 2 引数で呼んだりできるのです。また、マクロは、コンパイラがコードの意味を解釈する前に展 
開されるので、例えば、与えられた型にトレイトを実装できます。関数ではできません。何故なら、 
関数は実行時に呼ばれ、トレイトはコンパイル時に実装される必要があるからです。 

関数ではなくマクロを実装する欠点は、 Rust コードを記述する Rust コードを書いているので、関 
数定義よりもマクロ定義は複雑になることです。この間接性のために、マクロ定義は一般的に、関数 
定義よりも、読みにくく、わかりにくく、管理しづらいです。 

マクロと関数の別の違いは、マクロ定義は、関数定義のようには、モジュール内で名前空間分けさ 
れないことです。外部クレートを使用する際に予期しない名前衝突を回避するために、 #[ macro _ use ] 
注釈を使用して、外部クレートをスコープに導入するのと同時に、自分のプロジェクトのスコープに 
マクロを明示的に導入しなければなりません。以下の例は、 serde クレートに定義されているマクロ 
全部を現在のクレートのスコープに導入するでしょう： 

# [ macro_useJ 
extern crate serde ; 

この明示的注釈なしに extern crate が規定でスコープにマクロを導入できたら、偶然同じ名前の 
マクロを定義している2つのクレートを使用できなくなるでしょう。現実的には、この衝突はあまり 
起きませんが、使用するクレートが増えるほど、可能性は高まります。 

マクロと 関数にはもう一つ、重要な違いがあります：ファイル内で呼び出す前に マクロはスコープ 
に導入しなければなりませんが、一方で関数はどこにでも定義でき、どこでも呼び出せます。 
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—般的なメタプログラミングのために macro _ rules ! で宣言的なマクロ 

Rust において、最もよく使用される形態のマクロは、宣言的マクロです。これらは時として、例に 
よるマクロ、 macro_rules! マクロ、あるいはただ単にマクロとも称されます。核となるのは、宣言的 
マクロは、 Rust の match 式に似た何かを書けるということです。第6章で議論したように、 match 式 
は、式を取り、式の結果の値をパターンと比較し、それからマッチしたパターンに紐づいたコードを 
実行する制御構造です。マクロも自身に紐づいたコードがあるパターンと値を比較します；この場面 
で値とは、マクロに渡されたリテラルの Rust のソースコードそのもの、パターンは、そのソースコー 
ドの構造と比較され、各パターンに紐づいたコードは、マクロに渡されたコードを置き換えるコード 
です。これは全て、コンパイル時に起きます。 

マクロを定義するには、 macro _ rules ! 構文を使用します。 vec !マクロが定義されている方法を見 
て、 macro _ rul . es ! を使用する方法を探究しましょう。 vec ! マクロを使用して特定の値で新しいべク 
夕を生成する方法は、第8章で講義しました。例えば、以下のマクロは、3つの整数を中身にする新 
しいべクタを生成します： 

let v : Vec < u 32> = vec ! [1 , 2， 3]; 

また、 vec ! マクロを使用して2整数のベクタや、5つの文字列スライスのベクタなども生成できま 
す。同じことを関数を使って行うことはできません。予め、値の数や型がわかっていないからです。 

リスト D -1 で些（いささ）か簡略化された vec ! マクロの定義を見かけましょう。 


# [ mocro _ export ] 
macro _ rules ! vec { 

($( $ x:expr )，* ) 二〉 { 

{ 

let mut temp_vec = Vec :: new () : 

$( 

temp _ vec . push ($ x ); 

)* 

temp_vec 

} 

}； 

} 

リスト D -1： vec ! マクロ定義の簡略化されたバージョン 

標準ライブラリの vec !マクロの実際の定義は、予め正確なメモリ量を確保するコードを含み 
ます。そのコードは、ここでは簡略化のために含まない最適化です。 

# [ macro _ export ] 注釈は、 マクロ を定義しているクレートがインポートされる度にこの マクロ が利 
用可能になるべきということを示しています。この注釈がなければ、この ク レートに依存する誰かが 
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#[ macro _ use ] 注釈を使用していても、このマクロはスコープに導入されないでしょう。 

それから、 macro _ rul . es ! でマクロ定義と定義しているマクロの名前をビックリマークな しで 始め 
ています。名前はこの場合 vec であり、マクロ定義の本体を意味する波括弧が続いています。 

vec ! 本体の構造は、 match 式の構造に類似しています。ここではパターン （$( $ x:expr )，* ) の 
1つのアーム、=> とこのパターンに紐づくコードのブロックが続きます。パターンが合致すれば、紐 
づいたコードのブロックが発されます。これがこのマクロの唯一のパターンであることを踏まえると、 
合致する合法的な方法は一つしかありません；それ以外は、全部エラーになるでしょう。より複雑な 
マクロには、2つ以上のアームがあるでしょう。 

マクロ定義で合法なパターン記法は、第18章で講義したパターン記法とは異なります。というの 
も、マクロのパターンは値ではなく、 Rust コードの構造に対してマッチされるからです。リスト D -1 
のパターンの部品がどんな意味か見ていきましょう；マクロパターン記法全ては参考文献をご覧くだ 
さい。 

まず、1組のカッコがパターン全体を囲んでいます。次にドル記号（$)、そして1組のカッコが続 
き、このかっこは、置き換えるコードで使用するためにかっこ内でパターンにマッチする値をキャブ 
チャします。 $() の内部には、 $ x : expr があり、これは任意の Rust 式にマッチし、その式に $ x とい 
う名前を与えます。 

$() に続くカンマは、 $() にキャブチャされるコードにマッチするコードの後に、区別を意味するリ 
テラルのカンマ文字が現れるという選択肢もあることを示唆しています。カンマに続く*は、パター 
ンが*の前にあるもの0個以上にマッチすることを指定しています。 

このマクロを vec ![ l ， 2，3];と呼び出すと、 $ x パターンは、3つの式1、2、3で3回マッチし 
ます。 

さて、このアームに紐づくコードの本体のパターンに目を向けましょう： $()* 部分内部の temp_vec 
• push () コードは、パターンがマッチした回数に応じて0回以上パターン内で $() にマッチする箇所 
ごとに生成されます。 $ x はマッチした式それぞれに置き換えられます。このマクロを vec ! [1，2， 3] ; 
と呼び出すと、このマクロ呼び出しを置き換え、生成されるコードは以下のようになるでしょう： 

let mut temp_vec = Vec : : newu ; 

temp _ vec . push (1); 

temp _ vec . push (2); 

temp _ vec . push (3); 

temp_vec 

任意の型のあらゆる数の引数を取り、指定した要素を含むベクタを生成するコードを生成できるマ 
クロを定義しました。 

多くの Rust プログラマは、マクロを書くよりも使う方が多いことを踏まえて、これ以上 
macro _ rules !を議論しません。マクロの書き方をもっと学ぶには、オンラインドキユメンテー 
シヨンか他のリソース、 “The Little Book of Rust Macros (訳注： Rust のマクロの小さな本）などを 
調べてください。 
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独自の derive のためのプロシージャルマクロ 

2畨目の形態のマクロは、より関数 （1 種の手続きです）に似ているので、プロシージャル■マクロ 
( proceduralmacro ; 訳注： 手続きマクロ）と呼ばれます。プロシージャルマクロは、宣言的マクロの 
ようにパターンにマッチさせ、そのコードを他のコードと置き換えるのではなく、入力として何らか 
の Rust コードを受け付け、そのコードを処理し、出力として何らかの Rust コードを生成します。こ 
れを執筆して いる 時点では、 derive 注釈にトレイト名を指定することで、型に自分のトレイトを実装 
できるプロシージャルマクロを定義できるだけです。 

hello_macro という関連関数が 1 つある HelloMacro というトレイトを定義する hello_macro と 
いうクレートを作成します。クレートの使用者に使用者の型に HelloMacro トレイトを実装すること 
を強制するのではなく、使用者が型を# [derive(HelloMacro) ] で注釈して hello_macro 関数の規定 
の実装を得られるように、プロシージャルマクロを提供します。規定の実装は、 Hello, Macro! My 
name is TypeName! ( 訳注： こんにちは、マクロ！僕の名前は TypeName だよ！）と出力し、ここで 
TypeName はこのトレイトが定義されている型の名前です。言い換えると、他のプログラマに我々のク 
レートを使用して、リスト D -2 のようなコードを書けるようにするクレートを記述します。 

フアイル名： src / main.rs 

extern crate hello_macro; 

#[ macro_usej 

extern crate hello_macro_denve; 
use hello_macro: : HelloMacro; 


#[ derive ( HelloMacro)J 
struct Pancakes; 

fn main() { 

Pancakes :: hello_macro(); 

} 

リスト D -2: 我々のプロシージャルマクロを使用した時にクレートの使用者が書けるようになる 

コード 

このコードは完成したら、 Hello, Macro! My name is Pancakes! (Pancakes: ホットケーキ）と出 
力します。最初の手順は、新しいライブラリクレートを作成することです。このように： 

$ cargo new heLlo_macro --lib 

次に HelloMacro トレイトと関連関数を定義します： 


フアイル名： src / lib.rs 
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pub trait HelloMacro { 
fn hello_macro(); 

} 

トレイトと関数があります。この時点でクレートの使用者は、以下のように、このトレイトを実装 
して所望の機能を達成できるでしょう。 

extern crate hello_macro; 

use heilo_macro::HelioMacro; 

struct Pancakes; 

impl HelloMacro for Pancakes { 
fn hello_macro() { 

println! ("Hello, Macro! My name is Pancakes! 11 ); 

} 

} 

fn main() { 

Pancakes :: hello_macro(); 

} 

しかしながら、使用者は、 hello_macro を使用したい型それぞれに実装ブロックを記述する必要が 
あります；この作業をしなくても済むようにしたいです。 

さらに、まだ トレイトが 実装されている型の名前を出力する heU 0 _ m aCr0 関数に規定の実装を提供 
することはできません： Rust には リフレクションの 能力がないので、型の名前を実行時に検索するこ 
とができないのです。 コンパイル 時に コード 生成する マクロが 必要です。 

注釈：リフレクションとは、実行時に型名や関数の中身などを取得する機能のことです。言語 
によって提供されていたりいなかったりしますが、実行時にメタデータがないと取得できない 
ので、 Rust や C ++ のようなアセンブリコードに翻訳され、パフォーマンスを要求される高級 
言語では、提供されないのが一般的と思われます。 

次の手順は、プロシージャルマクロを定義することです。これを執筆している時点では、プロシー 
ジャルマクロは、独自のクレートに存在する必要があります。最終的には、この制限は持ち上げられる 
可能性があります。クレートとマクロクレートを構成する慣習は以下の通りです： foo というクレート 
に対して、独自の derive プロシージャルマクロクレートは foo_derive と呼ばれます。 hello_macro 
プロジヱクト内に、 helAo_macro_deri ve と呼ばれる新しいクレートを開始しましょう： 

$ cargo new heLlo_macro_denve --lib 


2 つのクレートは緊密に関係しているので、 hello_macro クレートのデイレクトリ内にプロシージャ 
ルマクロクレートを作成しています。 hello macro のトレイト定義を変更したら、 hello macro_deri ve 
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のプロシージャルマクロの 実装 も 変更し な ければ な ら ないで しょう。2 つのクレートは 個別に公開 さ 
れる必要があり、これらの クレートを 使用する プログラマは、 両方を依存に追加し、 スコープに 導入 
する必要があるでしょう。代わりに、 hellc^macro クレートに 依存と して、 hello_macro_der*ive を 使 
用 させ、プロシージャルマクロのコードを 再 エクスポート すること もで きるでしょう。 プロジェクト 
の 構造に よっては、プログラマが derive 機能を使用した くなくても、 heU 0 _m aC r* 0 を 使用すること 
が可能に な ります。 

hello_macro_deri ve クレートをプロシージャ ルマ クロクレートと して宣言する必要があります。 
また、 すぐにわかる ように、 syn と quote クレートの 機能も必要になる ので、 依存として追加する必 
要があります。以下を hello_macro_der*ive の Cargo. tOIIll フアイルに追加してください： 

ファイル名： hello _ macro _ denve / Cargo.toml 


[lib] 

proc-macro = true 

[dependencies] 
syn = "0.11.11" 
quote = "0.3.15" 

プロシージャル マクロの 定義を開始するために、 heUo_macro_derive クレートの Src/lib.rS ファ 
イルにリスト D -3 のコードを配置してください。 impl_hello_macro 関数の定義を追加するまでこの 
コードは コンパイル できないことに注意してください。 

ファイル名： hello _ macro _ denve / src / lib.rs 

extern crate proc_macro; 
extern crate svn; 

#[ macro _ use ] 
extern crate quote; 

use proc_macro::TokenStream; 


#[ proc _ macro _ derive ( HelloMacro )] 

pub fn heLlo_macro_derive (input: TokenStream) -> TokenStream { 

// 型定義の文字列表現を構築する 

// Construct a string representation of the type definition 
let s = input .to_string(); 

// 文字列表現を構文解析する 

// Parse the string representation 

let ast = syn: : parse_derive_input(&s).unwrapO; 

// impl を構築する 
// Build the impl 
let gen = impl_hello_macro(&ast); 


// 生成された impl を返す 
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// Return the generated impl 
gen . parse().unwrapO 

} 

リスト D -3: Rust コードを処理するためにほとんどのプロシージャルマクロクレートに必要になる 

コード 

D -3 での関数の分け方に気付いてください；これは、目撃あるいは作成するほとんどのプロシー 
ジャルマクロクレートで同じになるでしょう。プロシージャルマクロを書くのが便利になるからで 
す。 impl _ hello _ macr*o 関数が呼ばれる箇所で行うことを選ぶものは、プロシージャルマクロの目的に 
よって異なるでしょう。 

3 つの新しいクレートを導入しました： proc_macro 、 syn 、 quote です。 proc_macro クレートは、 
Rust に付随してくるので、 Cargo . toml の依存に追加する必要はありませんでした。 pr * oc_macro ク 
レートにより、 Rust コードを Rust コードを含む文字列に変換できます。 syn クレートは、文字列か 
ら Rust コードを構文解析し、処理を行えるデータ構造にします。 quote クレートは、 syn データ構造 
を取り、 Rust コードに変換し直します。これらのクレートにより、扱いたい可能性のあるあらゆる種 
類の Rust コードを構文解析するのがはるかに単純になります： Rust コードの完全なバーサを書くの 
は、単純な作業ではないのです。 

hello _ macro_derive 関数は、ライブラリの使用者が型に# [ der * ive ( He 11 oMacr * o ) ] を指定した時に 
呼び出されます。その理由は、ここで hello _ macr " o _ der"ive 関数を pr * oc _ macro_derive で注釈し、卜 
レイト名に一致する HeUoMacro を指定したからです；これは、ほとんどのプロシージャルマクロが倣 
う慣習です。 

この関数はまず、 TokenStream からの input を to_stri ng を呼び出して String に変換します。こ 
の String は、 HeUoMacro を継承している Rust コードの文字列表現になります。リスト D -2 の例で、 
s は struct Pancakes ; という String 値になります。それが# [ derive ( HelloMacro )] 注釈を追加した 
Rust コードだからです。 

注釈：これを執筆している時点では、 TokenStream は文字列にしか変換できません。将来的に 
はよりリツチな API になるでしょう。 

さて、 Rust コードの String をそれから解釈して処理を実行できるデータ構造に構文解析する必要 
があります。ここで syn が登場します。 syn の parse _ derive_input 関数は、 String を取り、構文解析さ 
れた Rust コードを表す Deri velnput 構造体を返します。以下のコードは、文字列 struct Pancakes ; 
を構文解析して得られる Derivelnput 構造体の関係のある部分を表示しています： 

Den velnput i 
II -- snip -- 


ident : Ident ( 
" Pancakes " 



付録 


561 


body : Struct ( 

Unit 

) 

} 

この構造体のフィールドは、構文解析した Rust コードが Pancakes という ident (識別子、つまり 
名前）のユニット構造体であることを示しています。この構造体には Rust コードのあらゆる部分を記 
述するフィールドがもっと多くあります ； Deri velnput の syn ドキュメンテーションで詳細を確認し 
てください。 

この時点では、含みたい新しい RllSt コードを構築する impl _ hello _ macro 関数を定義していませ 
ん。でもその前に、この hello _ macro _ derive 関数の最後の部分で quote クレートの parse 関数を使 
用して、 impl _ hello _ macro 関数の出力を TokenStream に変換し直していることに注目してください。 
返された TokenStream をクレートの使用者が書いた コードに 追加しているので、クレートを コンパイ 
ルすると、我々が提供している追加の機能を得られます。 

parse _ der * ive _ input か parse 関数がここで失敗したら、 unwrap を呼び出してパニックしているこ 
とにお気付きかもしれません。 エラー 時にパニックするのは、プロシージャルマクロコードでは必要 
なことです。何故なら、卩「〇〇_〇13(：「〇_〇16门' ve 関数は、プロシージャルマクロ API に従うように Result 
ではなく、 TokenStream を返さなければならないからです。 unwrap を使用してこの例を簡略化するこ 
とを選択しました；プロダクションコードでは、 panic ! か expect を使用して何が間違っていたのか 
よ り 具体的な エラー メッセージを提供すべきです。 

今や、 TokenStream からの注釈された Rust コードを String と Deri velnput インスタンスに変換 
するコードができたので、注釈された型に HelloMacro トレイトを実装するコードを生成しましょう： 

フアイル名： hello _ macro _ denve / src / lib.rs 

fn impL _ hello _ macro (. ast : & svn : : Denvelnput ; -> quote : :Tokens { 
let name = & ast . ident ; 
quote ! { 

impl HelloMacro for #name { 
fn hello _ macro () { 

println ! (" Hello , Macro ! My name is {}" , stringify ! (# name )); 

} 



} 


ast.ident で注釈された型の名前（識別子）を含む Ident 構造体インスタンスを得ています。リスト 
D -2 のコードは、 name が Ident ( n Pancakes n ) になることを指定しています。 

quote ! マクロは、返却し quote : :Tokens に変換したい RllSt コードを書かせてくれます。このマ 
クロはまた、非常にかっこいいテンプレート機構も提供してくれます；# name と書け、 quote ! は、そ 
れを name という変数の値と置き換えます。普通のマクロが動作するのと似た繰り返しさえ行えます。 
完全なイントロダクションは、 quote クレートの d 0 C をご確認ください。 
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プロシージャル マクロに 使用者が注釈した型に対して HeUoMacro トレイトの実装を生成してほし 
く、これは# name を使用することで得られます 0 トレイトの実装には1つの関数 helAo _ macro があ 
り、この本体に提供したい機能が含まれています： Hello , Macro ! My name is ^ そして、注釈した型 
の名前を出力する機能です。 

ここで 使用した stringify ! マクロは、 言語に埋め込まれています。1+ 2などのような Rust の式 
を取り、 コンパイル 時に"1+ 2 ” のような文字列リテラルにその式を変換します。これは、 format ! 
や println ! とは異なります 0 こちらは、式を評価し、そしてその結果を Stri ng に変換します 0 #name 
入力が文字通り出力される式という可能性もあるので、 stringify ! を使用しています。 stringify ! 
を使用すると、 コンパイル 時に# name を文字列リテラルに変換する ことで、 メモリ確保しなくても済 
みます。 

この 時点で 、 cargo build は helAo _ macro と helAo _ macro _ derive の両方で成功するはずです。 こ 
れらのクレートをリスト D -2 のコードにフックして、プロシージャルマクロが動くところを確認 
しましょう！ cargo new --bin pancakes で projects ディレクトリに新しいバイナリプロジェク 
卜を作成してください。 helAo _ macr * o と heVLo _ macro _ derive を依存として pancakes クレートの 
CarSfO . tOml に追加する必要があります。自分のバージョンの he 11 o _ macro と heHo _ macro_deri ve 
を https :// crates . io / に公開するつもりなら、普通の依存になるでしょう；そうでなければ、以下の 
ように path 依存として指定できます： 

[ dependencies 」 

hello_macro = { path = "../ hello _ macro " } 

hello _ macro_derive = { path = "../ hello _ macro / hello _ macro _ derive " } 

リスト D -2 のコードを Src / ltiaill . rS に配置し 、 cargo run を実行してください： Hello , Macro ! 
My name is Pancakes と出力するはずです。プロシージャルマクロの HelloMacro トレイトの実装は、 
pancakes クレートが実装する必要なく、包含されました；# [derive ( HelloMacro )] がトレイトの実装 
を追加したのです。 

マクロの未来 

将来的に Rust は、宣言的マクロとプロシージャルマクロを拡張するでしょう。 macro キーワード 
でより良い宣言的マクロシステムを使用し、 derive だけよりもよりパワフルな作業のより多くの種類 
のプロシージャルマクロを追加するでしょう。この本の出版時点ではこれらのシステムはまだ開発中 
です；最新の情報は、オンラインの Rust ドキュメンテーションをお調べください。 


付録 E : 本の翻訳 


英語以外の言語のリソースです。ほとんどは翻訳中です； Translations ラベルを確認して、新しい 
翻訳の手助けや開始したことをお知らせください！ 
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付録 F : 最新の機能 

この付録は、本の主な部分が完成してから安定版 Rust に追加された機能をドキュメント化してい 
ます。 


フィールド初期化省略 

fieldname を fieldname : fieldname の省略として記述することでデータ構造（構造体、 enum 、 ユ 
ニオン）を名前付きのフィールドで、初期化することができます。これにより、重複を減らし、コンパ 
クトな記法の初期化が許容されます。 

# [ derive ( Debug )] 
struct Person { 
name : String , 
age : u8 , 

} 

fn main () { 

// ピーター 

let name = String : : f rom (" Peter ") ; 
let age = 27; 

// フル記法： 

// Using full syntax : 

let peter = Person { name : name , age : age }; 

// ポー ティア 

let name = String : : from (" Portia ") ; 
let age = 27; 

// フィールド初期化省略： 

// Using field init shorthand : 
let portia = Person { name , age }; 

println ! ("{ :?}" , portia ); 

} 


ループから民る 

loop の1つの使用法は、スレッドが仕事を終えたか確認するなど、失敗する可能性のあることを 
知っている処理を再試行することです。ですが、その処理の結果を残りのコードに渡す必要がある可 
能性があります。それをループを停止させるために使用する break 式に追加したら、 break したルー 
プから返ってきます。 
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fn main () { 

let mut counter = 0; 

let result = loop { 
counter +=1; 

if counter ==10 { 

break counter 女 2; 

} 

}； 

assert _ eq ! ( result , 20); 


use 宣言のネストされたグループ 

多くの異なるサブモジュールがある複雑なモジュール木があり、それぞれからいくつかの要素をイ 
ンポートする必要があるなら、同じ宣言の全インポートをグループ化し、コードを綺麗に保ち、ベー 
スモジュールの名前を繰り返すのを回避するのが有用になる可能性があります。 

use 宣言は、単純なインポートとグロブを使用したもの両方に対して、そのような場合に手助けに 
なるネストをサポートしています。例を挙げれば、このコード片は、 bar 、 Foo 、 baz の全要素 、 Bar 
をインポートします。 

# #! [ aLiow ( unused _ imports , dead _ code )] 

# 

# 

# 

# 

# 

# 

# 

# 

# 

# 

# 

# 

use foo :: { 

bar : : { self , Foo }, 
baz , quux :: Bar }, 


mod foo { 

pub mod bar { 

pub type Foo =(); 

} 

pub mod baz { 

pub mod quux { 

pub type Bar =(); 

} 

} 


# 

# fn main () {} 
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境界を含む範囲 

以前は、範囲を式として使用する際、••でなければならず、これは上限を含まない一方、 パターン 
は.…を使用しなければならず、これは、上限を含みます。現在では、が式と範囲の文脈両方で上 
限を含む範囲の記法として受け付けられます。 

fn mann () { 

for i in 0 ••=10 { 
match i { 

0 ••= 5 => println ! ("{}: low " , i ), 

6 ••=10 => println ! ("{} : high " , i ), 

_ => println ! ("{} : out of range " , i ), 



} 

.••記法は それでも、 match では受け付けられ ますが、 式では受け付けられません。 ..= を使用す 
べきです。 


128 ビット整数 

Rustl .26.0 で128ビットの整数基本型が追加されました： 

• ui 28 :範囲[0, 2128 -1] の128ビットの非負整数 

• ii 28 :範囲[-(2127)，2127 -1] の128ビットの符号付き整数 

これらの基本型は、 LLVM サボート経由で効率的に実装されています。ネイティブに128ビット 
整数をサポートしないプラットフォームですら利用可能で、他の整数型のように使用できます。 

これらの基本型は、特定の暗号化アルゴリズムなど、非常に大きな整数を効率的に使用する必要の 
あるアルゴリズムで、とても有用です。 


付録 G: Rust が作られ方と "Nightly Rust" 

この付録は、 Rust のでき方と、それが Rust 開発者としてあなたにどう影響するかについてです。 
この本の出力は安定版 Rust 1.21.0 で生成されていますが、 コンパイル できるいかなる例も、それよ 
り 新しい Rust のどんな安定版でも コンパイル でき続けられるはずということに触れました。この節 
は、これが本当のことであると保証する方法を説明します！ 


停滞なしの安定性 

言語として、 Rust はコードの安定性について大いに注意しています。 Rust には、その上に建築で 
きる岩のように硬い基礎であってほしく、物事が定期的に変わっていたら、それは実現できません。 
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同時に新しい機能で実験できなければ、もはや何も変更できないリリースの時まで、重大な瑕疵（か 
し）を発見できなくなるかもしれません。 

この問題に対する我々の解決策は「停滞なしの安定性」と呼ばれるもので、ガイドの原則は以下の 
通りです：安定版 Rust の新しいバージョ ン にアップグレードするのを恐れる必要は何もないはずで 
す。各アップグレートは痛みのないもののはずですが、新しい機能、より少ないバグ、高速な コンパ 
イル時間も齎すべきです。 

シュポシュポ！リリースチヤンネルと列車に乗ること 

Rust 開発は、電車のダイヤに合わせて処理されます。つまり、全開発は Rust リポジトリの master 
ブランチで行われます。リリースはソフトウエアのリリーストレインモデル (software release train 
model) に従い、これは Cisco IOS や他のソフトウェアプロジェクトで活用されています。 Rust に 
はリリースチヤンネルが3つあります： 

注釈： software release train model とは、あるバージョンのソフトウェアリリースの順番 
を列車に見立て、列車のダイヤのように、決まった間隔でリリースに持って行く手法のことの 
模様。一つの列車は、 Rust の場合、ナイトリー、ベータ、安定版の順に「駅」に停車していく 
ものと思われる。 

• ナイトリー 
• ベータ 
• 安定版 

多くの Rust 開発者は主に安定版チャンネルを使用しますが、新しい実験的な機能を試したい方は、 
ナイトリーやベータを使用するかもしれません。 

こちらが、開発とリリースプロセスの動き方の例です： Rust チームが Rustl.5 のリリースに取り 
掛かっていると想定しましょう。そのリリースは、2015年の11月に発生しましたが、現実的なバー 
ジョンナンバーを与えてくれるでしょう。新しい機能が Rust に追加されます：新しいコミットが 
master ブランチに着地します。毎晩、新しいナイトリ版の Rust が生成されます。毎日がリリース日 
で、これらのリリースは、リリースインフラにより自動で作成されます。故に、時間が経てばリリー 
スは、毎晩1回、以下のような見た目になります： 

nightly : *--*--* 

6 週間ごとに、新しいリリースを準備するタイミングになります！ Rust リポジトリの beta ブラン 
チが、ナイトリで使用される master ブランチから枝分かれします。さて、リリースが二つになりま 
した： 

nightly : *--*--* 


beta : 


■k 
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ほとんどの Rust ユーザはベータリリースを積極的には使用しませんが、自身の CI システム内で 
ベータに対してテストを行い、 Rust が不具合の可能性を発見するのを手伝います。その間も、やはり 
ナイトリリリースは毎晚あります： 

注釈： CI は Continuous Integration (継続統合といったところか）のことと思われる。開発者 
のコードを1日に何度も、メインのブランチに統合することらしい。 

nightly : *--*--*--*--* 

I 

beta : ★ 

不具合が見つかったとしましょう。よいことに、不具合が安定版のリリースにこっそり持ち込まれ 
る前にベータリリースをテストする時間がありました！修正が master に適用されるので、ナイトリ 
は修正され、それから修正が beta ブランチにバックポートされ、ベータの新しいリリースが生成さ 
れます： 

nightly : 

I 

beta : 山--------‘ 

最初のベータが作成されてから6週間後、安定版のリリースの時間です！ stable ブランチが beta 
ブランチから生成されます： 


nightly : 

I 

beta : 女--------* 

I 

stable : ★ 


やりました！ Rustl.5 が完了しました！ですが、 1 つ忘れていることがあります： 6 週間が経過し 
たので、次のバージョンの Rust(1.6) の新しいベータも必要です。従って、 stable が beta から枝分 
かれした後に、次のバージョンの beta が nightly から再度枝分かれします： 

m ghtly : * - - * - - * - - ★--* - - * - * - * 

I I 

beta : ~k 

I 

stable : ★ 

これが「トレイン •モデル」 と呼ばれます。6週間ごとにリリースが「駅を出発する」からですが、 
安定版リリースとして到着する前にベータチャンネルの旅をそれでもしなければなりません。 

Rust は 6 週間ごとに時計仕掛けのようにリリースされます。ある Rust V リースの日付を知ってい 
れば、次のリリースの日付もわかります： 6週間後です。6週間ごとにリリースを組むことのいい側面 
は、次の列車がすぐにやってくることです。ある機能が偶然、特定のリリースを逃しても、心配する 
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必要はありません：別のリリースがすぐに起きます！これにより、リリースの締め切りが近い洗練さ 
れていない可能性のある機能をこっそり持ち込むプレッシャーが減る助けになるのです。 

このプロセスのおかげで、 Rust の次のビルドを常に確認し、アップグレードするのが容易であると 
自身に対して確かめることができます：ベータリリースが予想した通りに動かなければ、 チームに 報 
告して、次の安定版のリリースが起きる前に直してもらうことができるのです！ベータリリースでの 
破損はどちらかといえば稀ですが、 rustc もソフトウェアの一種であり、バグは確実に存在します。 

安定しない機能 

このリリースモデルにはもう一つ掴み所があります：安定しない機能です。 Rust は「機能フラグ」 
と呼ばれるテクニックを使用して、あるリリースで有効にする機能を決定します。新しい機能が活発 
に開発中なら、 master に着地し、故にナイトリーでは機能フラグの背後に存在します。ユーザとし 
て、絶賛作業中の機能を試したいとお望みならば、可能ですが、ナイトリリリースの Rust を使用し、 
ソースコードに適切なフラグを注釈して同意しなければなりません。 

ベータか安定リリースの Rust を使用しているなら、機能フラグは使用できません。これが、永遠 
に安定であると宣言する前に、新しい機能を実用に供することができる鍵になっています。最先端を 
選択するのをお望みの方はそうすることができ、岩のように硬い経験をお望みの方は、安定版に執着 
し自分のコードが壊れることはないとわかります。停滞なしの安定性です。 

この本は安定な機能についての情報のみ含んでいます。現在進行形の機能は、変化中であり、確実 
にこの本が執筆された時と安定版ビルドで有効化された時で異なるからです。ナイトリ限定の機能に 
ついてのドキュメンテーシヨンは、オンラインで発見できます。 

Rustup と Rust ナイトリの役目 

rustup は、グローバルかプロジェクトごとに Rust のリリースチャンネルを変更しやすくしてくれ 
ます。標準では、安定版の Rust がインストールされます。例えば、ナイトリをインストールするには: 

$ rustup install nightly 

rustup でインストールした全ツールチェーン （ Rust のリリースと関連するコンポーネント）も確認 
できます。こちらは、著者の一人の Windows コンピュータの例です： 

> rustup toolchain list 
stable-x86_64-pc-windows-msvc (derault) 
beta-x86_64-pc-windows-msvc 
nightly-x86_64-pc-windows-msvc 

おわかりのように、安定版のツールチェーンが標準です。ほとんどの Rust ユーザは、ほとんどの 
場合、安定版を使用します。あなたもほとんどの場合安定版を使用したい可能性がありますが、最前 
線の機能が気になるので、特定のプロジェクトではナイトリを使用したいかもしれません。そうする 
ためには、そのプロジェクトのディレクトリで rustup override を使用して、そのディレクトリにい 
る時に、 rustup が使用するべきツールチェーンとしてナイトリ版のものをセットします。 
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$ cd ~/projects/needs-nightly 
$ rustup override add mghtLv 

これで 7projects/needs-nightly 内で rustc や cargo を呼び出す度に、 rustup は規定の安定版の 
Rust ではなく、ナイトリ Rust を使用していることを確かめます。 Rust プロジェクトが大量にある 
時には、重宝します。 


RFC プロセスとチーム 

では、これらの新しい機能をどう習うのでしょうか？ Rust の開発モデルは、 Request For 
Comments (RFC; コメントの要求）プロセスに従っています。 Rust に改善を行いたければ 、 RFC 
と呼ばれる提案を書き上げます。 

誰もが RFC を書いて Rust を改善でき、提案は Rust チームにより査読され議論され、このチーム 
は多くの話題のサブチームから構成されています。 Rust の Web サイトにはチームの完全なリストが 
あり、プロジヱタトの各分野のチームも含みます：言語設計、コンパイラ実装、インフラ、ドキュメ 
ン テーシ ヨンなどです。適切なチームが提案とコメントを読み、自身のコメントを書き、最終的にそ 
の機能を受け入れるか拒否するかの同意があります。 

機能が受け入れられれば、 Rust リポジトリで issue が開かれ、誰かがそれを実装します。うまく 
実装できる人は、そもそもその機能を提案した人ではないかもしれません！実装の準備ができたら、 
「安定しない機能」節で議論したように、機能ゲートの背後の master に着地します。 

時間経過後、一旦ナイトリリリースを使用する Rust 開発者が新しい機能を試すことができたら、 
チームのメンバー がその機能と、ナイトリでどう機能しているかに ついて 議論し、安定版の Rust に 
導入すべきかどうか決定します。決定が進行させることだったら、機能ゲートは取り除かれ、その機 
能はもう安定と考えられます！ Rust の新しい安定版リリースまで、列車に乗っているのです。 



